Most teams can't answer this question: "How healthy is our design system?"
They have components in Figma. They use some design tokens. Developers reference a Storybook maybe once a week. But is it a system, or just a collection of files?
This assessment gives you a health score from 0 to 100. It covers five critical areas: tokens, components, accessibility, handoff, and Storybook. Score yourself. Find your bottleneck. Fix it in one sprint.
Why a Health Score Matters
A design system compounds. Small improvements create leverage. Tokens reduce design drift. Components reduce rework. Clean handoff reduces dev time. Accessibility compliance keeps you compliant and attracts customers.
But you can't improve what you can't measure. Most teams spend a year iterating on the wrong problems. This assessment lets you see clearly: where are you strong? Where are you weak? What should you fix first?
How to Use This Assessment
You'll see 10 questions. Each is worth 10 points. Answer honestly. If you're not sure, score conservatively—it's better to underestimate.
Give yourself one point per criterion met within each question. So if a question lists 10 criteria, and you meet 7, that's 7 points out of 10.
Have your design lead, product manager, and tech lead each score independently. Compare notes. The gap between how designers and developers score is often revealing—it shows where communication breaks down.
After scoring, move to the interpretation section. Then act on one area this sprint.
The Assessment (100 points total)
- You have a documented token structure (primitives, semantic, component layers)
- All color values in Figma use token variables, not hex codes
- All spacing values in Figma use token variables
- All typography uses design tokens
- Tokens are exported to code (CSS/Tailwind/SCSS)
- Light and dark mode tokens exist and are complete
- Tokens follow a naming convention (color-semantic-*, spacing-scale-*, etc.)
- Token documentation exists (where tokens live, how to use them)
- A new developer can find and use tokens within 30 minutes
- You have a process for adding new tokens (not ad-hoc)
- You have a component library documented somewhere (Figma or Storybook)
- Core components exist (Button, Input, Card, Modal, Dropdown)
- Components use variants (not separate copies)
- Every component has a clear purpose documented
- Components use tokens internally, not hardcoded values
- Component naming is consistent and predictable
- A designer can use the library without asking questions
- Developers know which components exist before building
- You have >80% component reuse in your product
- You have a component proposal/governance process
- Contrast ratios meet WCAG AA for all text (4.5:1+)
- Form labels are always paired with inputs
- Color is never the only way to convey information
- Icon buttons have text labels or aria-labels
- Focus states are visible and clear
- All interactive elements are keyboard accessible
- You've tested with a screen reader in the past 6 months
- Accessibility requirements are listed in your design spec
- Developers know the accessible HTML semantics before building
- You have a process to catch accessibility bugs before shipping
- You have a standard handoff format/template
- Specs include all component states (default, hover, active, error, loading, disabled)
- Specs include all breakpoints (mobile, tablet, desktop)
- Specs show token names, not hex/px values
- Specs are linked to live components (Code Connect or similar)
- Developers ask fewer than 3 clarifying questions per feature
- Time from "design approved" to "dev starts" is <2 days
- Production matches the design spec >90% of the time
- Designers and developers use the same component names
- You track handoff turnaround time as a metric
- You have a Storybook instance that developers use weekly
- Core components have stories (Button, Input, etc.)
- Stories include all component variants
- Stories show usage examples and props documentation
- Stories are automatically generated from code or manual but current
- Figma components link to Storybook stories
- You have >70% story coverage of your component library
- A new developer references Storybook before building
- Stories use actual tokens, not hardcoded styles
- You have a process to keep Storybook in sync with component code
Interpreting Your Score
0-20 points: Critical
Your design system is not yet a system—it's a collection of artifacts. Start with foundations: name everything consistently, document tokens, create a handoff template. You'll gain the most leverage from the smallest improvements here.
21-40 points: Fragmented
You have some pieces in place, but they don't connect. Tokens exist but don't get used. Components exist but aren't documented. Design and dev work in parallel, not together. Pick one area: either tokens or handoff. Build it end-to-end (Figma → export → code). Prove the pattern works. Scale it.
41-60 points: Functional
Your system works, but has gaps. Handoff is decent but still has back-and-forth. Storybook exists but isn't always current. Components are good but accessibility has gaps. You're at the inflection point where small improvements unlock big velocity gains. Focus on accessibility compliance and handoff speed. These move the needle.
61-80 points: Mature
Your system is healthy and scales reasonably. Handoff is smooth. Tokens are organized. Storybook is used. The gaps are usually in accessibility detail, component coverage at the edges (less common patterns), or automation (Storybook staying in sync). Work on completeness: fill in the missing components, tighten accessibility, automate updates.
81-100 points: Exceptional
Your system is a competitive advantage. Design and dev move as one. Tokens flow automatically. Storybook is the source of truth. Accessibility is baked in. You're spending time on edge cases and scaling patterns across new domains (maybe from web to mobile, or new product lines). Focus on maintaining momentum and documenting why things work the way they do—your system is a model.
The Highest-Leverage Fixes
If you scored under 40: Fix tokens first. Not because tokens are the most visible, but because every other part of the system depends on them. Once tokens are clean and exported, component work is 3x faster, handoff is clearer, and accessibility improves. Invest one sprint here.
If you scored 40-60: Fix handoff next. Add a spec template. Document all states. Link Figma to Storybook. This single change will reduce dev rework, make QA faster, and give you data on where the actual bottlenecks are.
If you scored 60-80: Fix accessibility gaps. Audit contrast. Label all icons. Test with a screen reader. This work is mandatory (EU Accessibility Act, ADA compliance, customer expectations) and usually the easiest gap to close. One audit, one sprint, compliance reached.
If you scored over 80: You've built something that works. The opportunity now is scaling it—adding coverage, automating updates, extending to new platforms. Document what you've built. You might be selling this as a service someday.