Milestone map
Milestone map
3 milestones
Audit Existing UI and Produce Design System Architecture Document
3–4 weeks
A design system is a product, not a library. Before building, audit the current product UI for inconsistencies and produce an architecture document answering: what are the design tokens, how do components relate to patterns, how will versioning work, and how will adoption happen without a big-bang rewrite. This milestone satisfies the Engineering Design Triad: design artifact.
Proof required
Submit: (a) a UI audit of the existing product identifying 5–10 component inconsistencies or duplicate implementations that the system will resolve, with screenshots, (b) the system architecture document (minimum 1,500 words) covering: token architecture (colour, spacing, typography at minimum), component hierarchy, versioning strategy, and incremental adoption roadmap, and (c) decision records for the two most significant architectural decisions explaining why alternatives were rejected.
What gets checked
- UI audit identifies specific instances with screenshots — not general statements about 'inconsistent spacing'
- Architecture document answers all four questions: tokens, hierarchy, versioning, adoption
- Decision records state why alternatives were rejected
Common mistakes
- Architecture document describes only the component library, not the token layer — tokens are the foundation
- Adoption roadmap assumes a big-bang replacement rather than incremental migration
Resources
What a verifier looks for
- Review the architecture document for the adoption roadmap: does it provide a path for existing product teams to adopt without a rewrite?
- Check the token architecture: does it define semantic tokens (colour.text.primary) that abstract over primitive tokens (palette.blue.700), or just a list of colour values?
Build Token Layer and Three Accessible Production-Ready Components
6–8 weeks
Implement the design token layer and three production-ready components: one primitive (Button or Input), one composite (Card or Modal), and one interaction-heavy component (Dropdown or Tooltip). All three must be WCAG 2.1 AA accessible, tested, and documented in Storybook. This milestone satisfies the Engineering Design Triad: analysis artifact via accessibility audit.
Proof required
Submit: (a) a public repository containing the design token files, all three components with full stories in Storybook, and component tests (minimum 80% branch coverage each), (b) an accessibility audit report for all three components using a free tool (Axe, WAVE, or Lighthouse) showing WCAG 2.1 AA results with any issues resolved, and (c) a live Storybook deployment URL (GitHub Pages, Netlify free tier, or Vercel free tier).
What gets checked
- All three components pass WCAG 2.1 AA — Axe issues must be resolved before submission
- Test coverage report shows at least 80% branch coverage per component
- Storybook deployment is live and accessible
Common mistakes
- Components built without accessibility testing — accessibility must be validated before claiming 'production-ready'
- Stories only show the default state — variants, hover, focus, disabled, and error states must all be represented
Resources
What a verifier looks for
- Visit the Storybook URL and interact: does the Button receive keyboard focus? Does the Modal trap focus? Does the Dropdown close on Escape?
- Review the accessibility audit report: are there WCAG 2.1 AA failures? If yes, the milestone is not complete.
Ship to Consumers, Complete Documentation, and Defend Architecture
3–4 weeks
Complete the documentation (component API reference, token docs, getting started guide, contribution guide) and ship the system to at least one real consumer team. Gather feedback from an adoption session. Present the complete architecture to a senior engineer or design systems expert who challenges at least two architectural decisions. This completes the Engineering Design Triad: documentation artifact.
Proof required
Submit: (a) the complete documentation site or Storybook docs (API reference for all three components, getting started guide, and contribution guide), (b) evidence of adoption by a real consumer team (a commit or PR in another repository using the system, or a recording showing a non-system-team engineer integrating one component), and (c) a Q&A log from the architecture review (minimum 400 words with at least two challenges to architectural decisions and your responses).
What gets checked
- Documentation covers all four required areas — a missing contribution guide blocks future adoption
- Consumer adoption evidence is from a real different person, not a personal project of the submitter
- Q&A log shows genuine architectural challenges with alternatives proposed
Common mistakes
- Documentation describes what components do rather than how to use them — API reference requires prop types, defaults, and usage examples
- 'Adoption' by another personal project of the same submitter
Resources
What a verifier looks for
- Challenge the most consequential decision: 'You chose CSS custom properties over CSS-in-JS — walk me through how you'd handle a consumer who needs runtime theme switching.'
- Provide a written confirmation (minimum 200 words) of your background, the specific decisions you challenged, and your assessment of the submitter's ability to reason about design system architecture and adoption.