Spring Design Library — Product Decision Framework

Audience: Leadership, product, design, engineering
Purpose: Define when to do rebranding, feature development, and usability enhancement — and what gates must pass first
Last updated: June 2026
Framework reference: Marty Cagan, Inspired — four risks (value, usability, feasibility, viability)

---

Executive summary

Not every improvement should happen at once. This framework prevents:

• Rebranding too early — before the DS can be injected anywhere
• Feature sprawl — before the prototype proves value
• UX churn without baseline — before stakeholders have walked the flow

Rule of thumb: Publish the Application Flow first (M1). Then iterate in 2-week waves using the gates below.

---

Decision matrix

---

1. Feature development

Definition

Building new product capabilities: screens, flow steps, components, routing branches, integrations.

When to start

After M2 (internal validation) — not before stakeholders have walked the published AppFlow.

Gate checklist

• M1 publish complete — end-to-end demo works
• Stakeholder review completed — go/no-go recorded
• Backlog item tagged with risk it addresses (value / usability / feasibility / viability)
• Engineering feasibility confirmed (reuse vs new component decision)

Prioritization (Inspired)

Rank features by risk reduction, not by loudest request:

Examples in this project

Stop signals

• Stakeholders have not seen the current prototype
• Feature duplicates existing DS component without justification
• No designer sign-off on Figma source

---

2. Usability enhancement

Definition

Improving how users experience the product: copy tone, layout emphasis, trust/urgency framing, persona variants, drop-off reduction, declined/success state refinement.

When to start

Continuous from M2 onward — with spikes after each review cycle.

Unlike feature development, usability work can run in parallel with delivery once a baseline prototype exists.

Gate checklist

• Baseline prototype published (M1)
• Persona or segment identified (if variant)
• Change maps to UX strategy pillar (ux-strategy-logic.md)
• Designer approves copy/layout delta

Sources of truth

Cadence

Stop signals

• No baseline to compare against (pre-M1)
• Change contradicts approved Figma without UX deviation approval
• Purely cosmetic with no measurable UX intent

---

3. Rebranding and theme switching

Definition

• Rebranding: New application identity (Foundation, DPP partner, co-brand)
• Theme switching: Runtime or build-time swap of brand tokens while keeping shared layout/spacing/components

When to start

M6 (Week 13–15) only — after injectable DS is proven (M4) and architecture is aligned (M3).

Why not earlier

This aligns with Inspired: solve feasibility before scaling variants.

Prerequisites (all must pass)

• M1 — AppFlow publish-quality
• M3 — Architecture RFC approved
• M4 — Injectable guide validated; L1 restyle in <4h
• Token architecture supports semantic brand overrides
• DS covers AppFlow critical path (inputs, actions, modals)

Implementation rules

Testing before sign-off

• Switch theme → AppFlow restyles without code changes per screen
• Partner override affects brand tokens only
• Default Spring theme — M1 walkthrough still passes
• L1+L2 injectable adoption still works with theme active

Stop signals

• M4 not complete
• Hardcoded brand colours still in components (P2 cleanup incomplete)
• No partner token spec for DPP

---

4. Other common decisions

Token changes

Playground → package graduation

External npm publish

Production backend integration

---

Visual timeline of decision gates

flowchart TD
  publish[M1PublishAppFlow]
  validate[M2InternalValidation]
  arch[M3Architecture]
  inject[M4InjectableDS]
  playground[M5Playground]
  theme[M6RebrandTheme]

  publish --> validate
  validate --> features[FeatureDevelopment]
  validate --> usability[UsabilityEnhancement]
  validate --> arch
  arch --> inject
  inject --> theme
  validate --> playground
  inject --> playground

  features -.->|"gate: M2 backlog"| features
  usability -.->|"gate: M1 baseline"| usability
  theme -.->|"gate: M3+M4"| theme

---

Quick reference card (for meetings)

Boss asks: "Can we rebrand for Partner X next sprint?"
→ No, unless M4 injectable guide is done. Earliest: M6 (Oct 2026). Partner can use L1 tokens as interim.

Boss asks: "Can we add feature Y?"
→ Yes if M2 validation prioritized it and it reduces a named risk. No if stakeholders haven't walked the flow.

Boss asks: "Can we improve copy on step Z?"
→ Yes anytime after M1 publish. Use UX strategy + persona docs.

Boss asks: "Can we publish the design system to npm?"
→ After M3 architecture RFC — not before CI and consumption model are settled.

Boss asks: "When is the Application Flow live?"
→ M1 target: Jul 13, 2026 (1–2 weeks from kickoff). Prototype, not production.

---

Related documents