Design Systems
Scope
Covers
- Creating or upgrading a design system (tokens + components + guidelines)
- Using blockframes (lo-fi, system-aware wireframes) to lock logic before hi-fi execution
- Designing a future-ready visual foundation (depth/elevation, motion, texture) without breaking consistency
- Making the system easy for non-experts to use (guardrails, examples, starter templates)
- Driving adoption + governance (contribution model, champions, release cadence)
When to use
- “We need a design system / component library and a plan to build it.”
- “Our UI is inconsistent—define tokens + components + documentation to standardize.”
- “We want to refresh our UI style (more depth/texture/motion) without chaos.”
- “We need to scale design across teams or support enterprise customers with customization.”
- “We want faster hi-fi output by locking flows in lo-fi first.”
When NOT to use
- You’re defining a brand identity or logo system (different process).
- You need user research/discovery to decide *what* to build.
- You only need to ship one isolated UI change (just implement it).
- You’re doing pure front-end architecture unrelated to UI consistency.
Inputs
Minimum required
- Product + surfaces: web/iOS/Android; key flows
- Current state: existing UI kit/design system (if any), design tool (e.g., Figma), code stack (if relevant)
- Goals: speed, consistency, accessibility, scalability, customization, enterprise adoption
- Constraints: timeline, team ownership, level of engineering support, compliance/a11y needs
Missing-info strategy
- Ask up to 5 questions from references/INTAKE.md, then proceed with explicit assumptions.
- If platform/stack is unknown, assume a modern web product with a component library and design tokens.
- Do not request secrets or credentials.
Outputs (deliverables)
Produce a Design System Operating Pack in Markdown (in-chat by default; write to files if requested):
- Context snapshot (goals, constraints, success signals)
- Design system charter (mission, scope, principles, audiences, in/out)
- UI audit + operational blockers (what’s slowing teams down; what must standardize first)
- Blockframe-to-component map (lo-fi flows + mapping to components/tokens)
- Token model (taxonomy, naming rules, and initial token backlog—include elevation/depth)
- Component inventory + roadmap (tiers, prioritization, milestones)
- Documentation + enablement plan (non-designer-friendly, “teaches by structure”)
- Governance + adoption plan (contribution workflow, decision rights, champions, release cadence)
- Quality gate (checklists + rubric score) + Risks / Open questions / Next steps
Templates: references/TEMPLATES.md
Workflow (7 steps)
1) Intake + success definition (who is this for?)
- Inputs: User context; references/INTAKE.md.
- Actions: Confirm primary users of the system (designers, engineers, PMs, “non-designers”). Define success signals (cycle time, consistency, adoption, fewer UI bugs, faster onboarding).
- Outputs: Context snapshot (draft).
- Checks: Success is measurable or at least falsifiable (e.g., “80% of new screens use system components”).
2) Audit the current UI and find the operational “hook”
- Inputs: Screens/flows, existing components, pain points, enterprise needs (if any).
- Actions: Inventory inconsistencies (spacing/type/color/components), identify the operational blocker the system will remove (e.g., slow production, inconsistent UI, customization needs). Choose the first high-leverage slice.
- Outputs: UI audit + operational blockers list; initial scope slice.
- Checks: The first slice is narrow enough to ship but broad enough to set patterns.
3) Lock logic with blockframes (separate thinking from styling)
- Inputs: Key flows; current IA; constraints.
- Actions: Create or specify “blockframes” (lo-fi, system-aware wireframes). Map each block to intended components and token usage so hi-fi execution becomes faster and more consistent.
- Outputs: Blockframe-to-component map (v1).
- Checks: A reviewer can validate flow/IA without debating visual details.
4) Define the token model (make the future style changeable)
- Inputs: Brand constraints, accessibility targets, desired direction (e.g., depth/texture/motion).
- Actions: Define token taxonomy + naming; include elevation/depth and state tokens. If doing a visual refresh, design the token model so style can evolve without rewriting components.
- Outputs: Token model + token backlog (v1).
- Checks: Tokens support theming and states; accessibility constraints are addressed (contrast, focus, motion).
5) Define the component model + delivery plan
- Inputs: Audit + blockframes + token model; engineering constraints.
- Actions: Tier components (primitives → composites → patterns). Prioritize by reuse and user impact. Define milestones, owners, and acceptance criteria.
- Outputs: Component inventory + roadmap (milestones).
- Checks: Milestone 1 ships within 1–2 weeks and establishes “golden path” patterns.
6) Make it easy to use (guardrails for non-experts)
- Inputs: Target user types; common mistakes; documentation needs.
- Actions: Design documentation and component guidelines so they “teach by structure”: sensible defaults, constrained options, examples, do/don’t. Provide starter templates for common layouts.
- Outputs: Documentation + enablement plan (v1).
- Checks: A non-expert can assemble a consistent screen using templates with minimal training.
7) Governance + adoption + quality gate
- Inputs: Draft pack; stakeholder map; toolchain (Figma/Storybook/etc.).
- Actions: Define decision rights, contribution workflow, review gates, and release cadence. Create a champion/office-hours plan to drive adoption. Run references/CHECKLISTS.md and score with references/RUBRIC.md. Finalize Risks / Open questions / Next steps.
- Outputs: Final Design System Operating Pack.
- Checks: Ownership is unambiguous; adoption plan exists; quality bar is explicit and repeatable.
Quality gate (required)
- Use references/CHECKLISTS.md and references/RUBRIC.md.
- Always include: Risks, Open questions, Next steps.