Figma to Storybook Fidelity Checklist
See whether a coded component genuinely implements its design definition, or merely resembles it.
Why fidelity is not the same as looking right
Use this checklist before declaring a component done, when a component keeps getting reopened, or when design and engineering disagree about whether something matches.
A component can be pixel-accurate in its default state and wrong in every way that matters. Most fidelity failures are not visual. They live in the states nobody drew, the behaviour nobody specified, and the semantics nobody checked.
Work through one component at a time with the component open in Figma and the same component open in Storybook, side by side.
1. Structure
- Same variant set, same names, same order.
- Same properties exposed, and named the same way.
- Slots and content areas accept the same things.
- Nesting and composition rules are the same.
- Nothing exists in code that a designer cannot reach, and nothing exists in Figma that code cannot produce.
2. Tokens
- Colour, spacing, radius, typography and elevation come from tokens, not literals, on both sides.
- The token names match. A value matching by coincidence is not a match.
- Theme and mode variants resolve correctly in both.
- Responsive behaviour uses the same breakpoints.
3. States
Most drift lives here. Check every state that applies.
- Default, hover, active, focus, disabled.
- Loading, and what it does to layout.
- Empty, and whether it says anything useful.
- Error, including whether the message can be long.
- Selected, indeterminate, read-only.
- Overflow, with content longer than the design ever contained.
4. Behaviour
- Keyboard interaction: tab order, enter, escape, arrow keys where relevant.
- What happens on rapid repeat interaction.
- Whether an async action prevents duplicate submission.
- What the component does while the thing it triggered has not finished.
- Whether it recovers when the action fails.
5. Semantics and accessibility
- Correct element or role, not a styled div doing an impression of a button.
- Accessible name matches the visible label.
- Focus is visible and meets contrast requirements.
- Error and status changes are announced, not only shown.
- Touch targets are large enough on the smallest supported device.
- Colour is never the only carrier of meaning.
6. Documentation
- Storybook covers the states from section 3, not just the default.
- Usage guidance says when not to use this component.
- Known limitations are recorded rather than folklore.
Scoring it honestly
- 01
Structural mismatches
The component contract itself is unclear. Fix before anything else.
- 02
State gaps
The category Tcules finds most often, and the one that tends to cost most later. Each gap is a decision someone will improvise.
- 03
Semantic failures
Treat as defects, not polish.
- 04
Documentation gaps
Cheap to fix, and they compound.
What this does not tell you
It compares one component against its own definition. It will not tell you whether the definition is right, whether the component is used correctly in the product, or whether the library is worth its maintenance cost.
What to do next
If the same gaps recur across components, that is a systemic correspondence problem, and Figma and Storybook Alignment addresses it.
If the built product diverges even when the component is correct, the Design-to-Code Audit follows behaviour into the running interface, and starts with a free audit on one component or flow.
What to do next
If the same gaps recur across components, Figma and Storybook Alignment addresses it. If the built product diverges even when the component is correct, the Design-to-Code Audit follows behaviour into the running interface.