What should survive the trip from design to code?
A design-to-code workflow should preserve the product’s intent, interaction states, content hierarchy, and approved component decisions. Matching a static frame is only one part of the work. The implemented feature must also behave correctly with real data, different permissions, narrow layouts, and failed requests.
TDP’s product-context work connects a feature spec to existing components before generating an interface. The Figma-to-Storybook process shows why a component audit belongs before implementation: design and code may already disagree.
Use one real feature for this walkthrough. The goal is a small implementation that a designer and engineer can inspect together, with enough evidence to understand what changed and why.
Companion guide: Figma to Storybook
Open From Figma to Storybook: Build Components AI Can Use for TDP’s reusable prompts. Follow the source check, token audit, component specification, and Storybook implementation with your own Figma file and repository. Keep the prompts beside this walkthrough and review each result before moving to the next step. Access may require free signup.
Step 1. Bound the feature
Choose a task small enough to inspect end to end. “Redesign the dashboard” leaves too many decisions implicit. “Let an account owner change an invitation role before sending” gives the team a concrete behavior to design and verify. Record what this iteration intentionally leaves out.
Step 2. Specify the states
Write what the interface shows while loading, with no data, after success, and after failure. Add permission and validation rules where relevant. A static frame usually represents one state; the implementation must handle the others as well.
| State | Question to resolve |
|---|---|
| Default | What information is visible before action? |
| Loading | What stays usable while a request runs? |
| Error | Is entered work preserved, and how can the user recover? |
| Success | How does the user know the action completed? |
| Permission | Which actions are available to this actor? |
Step 3. Map decisions to the component library
List the components and token roles required for the flow. Link their implementations and relevant examples. Separate a missing capability from an aesthetic preference: extending a shared component has different consequences from changing a local layout. Have design and engineering agree on that boundary.
Step 4. Implement a reviewable slice
Give the agent or engineer the approved brief, component references, and constraints. Ask for a short implementation plan before a large change. Keep the first slice small enough that a reviewer can connect each changed file to the feature’s behavior.
Implement [bounded feature] from [approved specification].
Reuse [component paths] and [token source].
Cover the state matrix and preserve existing public interfaces.
Report changed files, verification results, and unresolved questions.
Step 5. Check behavior and visual decisions
Run the project’s appropriate checks. Then walk through the feature in the browser with keyboard input, narrow layouts, long content, and failure states. Record evidence against the criteria. Feed accepted changes back into the feature brief and component documentation so the next task starts from current information.
Worked example: a notifications panel with real states
Imagine a frame shows three unread notifications and a “Mark all as read” action. Before coding, ask what happens when there are no notifications, when the list is loading, when the request fails, and when one item has a very long title. Also decide whether the action applies to all records or only the visible page.
These questions affect component choice and data behavior. A prototype that assumes three tidy rows can hide pagination, truncation, and focus problems. Write the state matrix first, then map each state to approved components and product rules.
| State | Content requirement | Review question |
|---|---|---|
| Loading | Explain that content is being retrieved | Does the layout remain understandable? |
| Empty | Explain why the panel is empty | Is a next action useful or unnecessary? |
| Populated | Show realistic titles, dates, and status | Can users distinguish unread items without color alone? |
| Failed request | Explain the failure and recovery path | Does retry preserve context? |
| Updating | Reflect the pending operation | Can repeated activation create duplicate work? |
This is an illustrative matrix. Use only states supported by your feature and add the domain-specific cases it needs.
Map the frame to implementation before generating code
List the reusable components, their import paths, and any gaps. Identify whether the frame uses a variant the library actually supports. A visually similar component with different behavior may be the wrong choice, while a small approved extension may be better than a duplicate implementation.
Ask the agent to propose the mapping before editing. Review unsupported combinations and new dependencies at that point. It is easier to correct the plan before a generated screen spreads new conventions across several files.
Read the approved feature brief and design-system entry point.
Map the screen to existing components and tokens.
Identify missing states or unsupported combinations.
Implement one complete interaction using the approved mapping.
Report changed files, checks, and unresolved decisions.
Compare at the level where the decision lives
Review system details against the component library: type roles, spacing, focus treatment, and variants. Review product behavior against the feature brief: permissions, transitions, and outcomes. Review responsive composition against the actual layout and content. This keeps a visual preference from overriding a product requirement by accident.
Use side-by-side references for the same viewport, theme, and state. If they differ, determine whether the implementation drifted or the design reference is outdated. Record the resolved decision instead of repeatedly patching screenshots until they appear similar.
What belongs in the pull request?
Describe the user-visible behavior, the scope of the change, and the checks performed. Add screenshots for meaningful layout changes and a short interaction recording when static images cannot show the behavior. Link the approved brief and note any remaining gaps.
A helpful description says “the panel preserves its items when the refresh fails and exposes a retry action,” then explains how that was checked. “Updated UI” gives the reviewer little to evaluate. Do not claim a test passed because the agent said it ran; inspect the reported result and reproduce important flows.
Common implementation traps
A generated screen can duplicate a component because its export was hard to find. It can hardcode a color because the semantic role was undocumented. It can invent an empty-state action because the requirement only described populated content. These are different failures; fix the source rather than applying a generic instruction to “be more consistent.”
After approval, update the component guidance or product context that was missing. The next feature should benefit from what the team learned. See GitHub for designers for the review workflow and component documentation for the reusable contract.
Completion checklist
- Scope and exclusions are explicit.
- Important states have a defined outcome.
- Existing components were evaluated before new ones were created.
- Automated checks and browser review cover different failure modes.
- Documentation reflects the implemented behavior.
Common questions
Can a screenshot contain the full specification?
It can communicate visual decisions, but it rarely defines permissions, data rules, failure behavior, or every interaction state. Attach those requirements separately.
When should we use Figma?
Use it where it helps your team explore, compare, and approve decisions. Keep the approved outcomes accessible to the people implementing and verifying them.
Sources and TDP resources
- TDP’s design-to-code workflow article
- TDP’s Figma-to-Storybook resource provides a component-focused companion workflow.