When to use this workflow
Use the companion resource when an existing Figma component needs a working, documented implementation. Begin with a source audit rather than a screenshot conversion. The design file and production code may already disagree about values, states, or intended usage.
A worked example
In TDP’s demonstration, Dianne audits the Carrot variables and a button before building the Storybook version. The process identifies raw semantic colors, incomplete mappings, differing dimensions, and unresolved interaction rules. The useful sequence is to inspect, resolve decisions, implement, and then compare the result with the approved contract.
Decisions and common mistakes
For your own pilot, ask the agent to identify the source of each answer and separate facts, recommendations, and unknowns. Choose one component, document its anatomy and supported combinations, and create inspectable stories. Adapt the demonstration’s decisions to your product rather than copying its button behavior blindly.
What to hand off
Review the component in isolation and in a real page composition. Record intentional differences between Figma and code, then update the relevant source. The original companion guide remains available through its existing access flow; the related field guide provides the expanded public walkthrough.
Put the resource to work
1. Start with one concrete task
Bring: A Figma component, its states and tokens, and a project with Storybook configured.
First task: Build one component from the reference and add stories for its meaningful states before scaling the library.
Choose one component, screen, or team workflow to improve. Gather the existing decisions and write down the question you want this resource to help answer.
2. Open the source material
Open the original guide or presentation ↗
Use the original walkthrough alongside your project. Its existing access flow remains available on the original page.
3. Apply it with your project context
Follow the material in sequence and replace examples with your own product context. Record decisions as you go so another teammate can understand why the result changed.
4. Review the result
Compare the stories with Figma, test interactions and keyboard behavior, and document intentional differences.
Compare the output with the task’s acceptance criteria. Check factual claims, unsupported assumptions, and any changes to the interface. For code or design changes, review real states and behavior before treating the result as finished.
5. Keep what works
Save approved outputs with their source and ownership. Note which instructions helped, where the result needed correction, and what must be checked next time. Use the workflow below to connect this task to its next step.
Follow the related step-by-step field guide ↗
Completion checklist
- The inputs and intended result are explicit.
- Required files and tools are available in the chosen host.
- The result has been reviewed against the actual task.
- Limitations and follow-up checks are recorded.