Spring Design Library — Project Overview and Goals

Audience: Leadership, product, design, engineering
Purpose: Kickoff document — what we are building, why it matters, and how we measure success
Last updated: June 2026
Status: Active planning baseline

---

Executive summary

The Spring Design Library is the Opportunity Generation team's product platform for building, testing, and shipping customer-facing financial experiences. It is not just a component catalog — it is the infrastructure that lets us:

1. Prove product efficiency through a live Application Flow built entirely from the design system.
2. Iterate with designers, stakeholders, and developers on a shared prototype before production investment.
3. Inject Spring look-and-feel into any host app — including vibe-coded or third-party platforms — even when not every component exists yet.
4. Experiment safely in a Playground lane before graduating work into the canonical package.

First deliverable: Publish the Application Flow in 1–2 weeks (target: mid-July 2026). Everything else builds on that anchor.

---

Problem statement

---

Product vision

3–5 year vision: Spring Financial ships every customer-facing product from a shared, injectable design system that makes discovery fast and delivery predictable.

Near-term vision (12 weeks): A published Application Flow prototype, validated by internal stakeholders, with a documented path to adopt the design system on any React/Next.js host.

---

Strategic goals

---

OKRs (12 weeks post-publish)

---

Inspired framework (Marty Cagan)

We apply principles from Inspired: How to Create Tech Products Customers Love to avoid building features nobody needs.

Dual-track agile (not waterfall)

Discovery and delivery run in parallel by the same cross-functional team — not as sequential phases with handoffs.

flowchart LR
  subgraph discovery [DiscoveryTrack]
    proto[Prototype]
    risks[TestFourRisks]
    learn[LearnAndPrioritize]
  end
  subgraph delivery [DeliveryTrack]
    build[BuildAndHarden]
    ship[ShipAndMeasure]
  end
  proto --> risks --> learn
  learn --> build --> ship
  ship --> proto

Four risks to test at every decision

We prioritize backlog items by which risk they reduce, not by feature count.

Outcomes over outputs

We measure success by outcomes (stakeholder can walk the flow end-to-end; external app looks like Spring in 4 hours), not by shipping screen counts alone.

---

Current maturity (baseline)

Detailed implementation status: personal-loan-appflow-master-plan.md

---

What "publish" means (and what it does not)

Publish means (Week 1–2)

• Clickable Application Flow: start → name → … → analyzing → outcome without manual URL entry
• Gallery route: /library/page/appflow/personal-loan/start
• Standalone app mirrors the flow: /personal-loans/start
• Flow map + PageMapPopup usable for stakeholder walkthrough
• Manual walkthrough checklist signed by PM + designer
• npm run lint && npm run build pass

Publish does NOT mean

• Production application with backend APIs
• Full mobile layout pass on all 20+ screens
• npm package published externally
• Multi-brand theme switching
• All production branches and edge cases wired

---

Stakeholder map

---

Related documents