Rubric: Design System Architect
Purpose
Use this rubric to evaluate whether an engineer can design and govern a production design system rather than a component catalog.
Capability rubric
| Capability | Level 3 | Level 4 | Level 5 |
|---|---|---|---|
| Token architecture | Uses semantic tokens for common needs. | Designs token layers for theme, brand, state, density, and accessibility. | Evolves token strategy across products and brands. |
| Component API design | Builds reusable components. | Designs durable controlled, uncontrolled, headless, and compound APIs. | Establishes API standards and migration policies. |
| Accessibility contracts | Handles common keyboard and label requirements. | Specifies focus, keyboard, names, states, live regions, and escape behavior. | Makes accessibility difficult to regress across teams. |
| Package architecture | Publishes components safely. | Designs package boundaries, exports, peer dependencies, and release cadence. | Runs design system platform governance. |
| Theming and branding | Supports basic dark mode. | Supports multi-brand and white-label use without leaking product specifics. | Creates scalable brand governance with design partners. |
| Documentation | Documents usage. | Provides Storybook states, recipes, migration guidance, and anti-patterns. | Builds documentation that teaches product teams architecture judgment. |
| Adoption | Supports consumers reactively. | Plans migrations, codemods if needed, and deprecation windows. | Drives adoption across multiple teams while reducing local forks. |
| GenUI readiness | Has reusable components. | Defines which components are safe for generated UI. | Governs AI-facing component registries and schemas. |
Required evidence
- Token taxonomy.
- Component contract for one complex primitive.
- Accessibility verification notes.
- Package/release policy.
- Migration plan for one legacy component.
- Adoption scorecard.
Minimum passing standard
Readiness requires level 4 in component API design, accessibility contracts, package architecture, and adoption. A design system architect must be able to say no to visual-only components that encode unstable behavior.