Most teams have designers and backend engineers. The missing layer is often the ability to translate experience intent into production-ready frontend behavior.
A coding agent can reproduce the visible frame and still miss the product. Why does this component exist? When should it change, and what happens under pressure? Which details are non-negotiable? A better handoff would carry those answers through behavior, tests, and accessibility.
The result looks close and behaves wrong
The translation tax appears in review rounds, inconsistent states, duplicated components, accessibility repairs, and the endless sentence: “That’s not quite what we meant.”
A generated component can look polished while calculating the wrong thing. A control can imply that data will persist when it only changes local state.
Figma has to explain how the interface works
A useful Figma file uses consistent tokens rather than one-off values. Its components have purposeful variants. It defines empty, loading, error, partial, success, and recovery states. It shows long-content and responsive behavior. It names layers and frames predictably. It pairs real flow examples with component documentation.
The file should answer more than “What does it look like?”
It should also answer “What is this for? When should it appear? What can vary? What shouldn’t? What does the user need to understand? What happens next?”
Handoff becomes a conversation instead of a document drop
At Knurture, Figma and code are two views of the same system. Figma records the intended flows, states, and visual decisions. Code makes those decisions work through behavior, constraints, tests, and accessibility. The names and logic should mirror each other.
A component conversation is a shared record of one component’s design and code.
Fill-in card
One component conversation
For one component, record what the design file shows, what the coded version has to do, where it can be inspected, and the names and logic they share.
- Figma
- the flows, states, tokens, motion, examples, and edge cases the design file must show.
- Coded version
- the behavior, constraints, tests, accessibility, and extension rules it must follow.
- Working reference
- where someone can inspect the working version.
- Shared names and logic
- the names and logic that must match in Figma and code.
A designer and engineer—or a design agent and coding agent—should be able to discuss the same component without translating vocabulary first.
Example
One component conversation: the frame from the opening
The opening has a visible Figma frame and a coded version that behaves wrong. This example shows what each view establishes and what still needs a decision.
- Figma: the chosen layout. It may not show why a component exists, when it should change, what happens under pressure, or which details are non-negotiable.
- Coded version: what a coding agent reproduced from the visible frame. It looks close and behaves wrong.
- Working reference: Not known yet: Where can the team inspect the working version?
- Shared names and logic: Not known yet: Which names and logic must match in Figma and code?
Full-page generation compounds errors
A wrong assumption in one component spreads across the whole implementation.
A vertical slice is a small end-to-end part of the product. The team takes one component or journey from design through working code before moving to the next part.
Sequence map
Vertical slices
Take each slice through these steps.
- Implement: a component or journey slice.
- Compare: it with the intent.
- Correct: the system.
- Continue: to the next slice.
Preserve the reasoning in the component and docs so the next slice inherits better judgment. If a correction is a durable rule, it belongs in the system.
If it matters to trust, it belongs in the artifact
Coding agents handle the happy path well when the picture is clear. They guess at everything the picture can’t show.
Explicitly design:
- Focus, keyboard, and screen-reader behavior.
- Loading strategy: skeleton, optimistic, streamed, or blocked.
- Empty and error copy.
- Permission and approval states.
- Long text, localization, and responsive changes.
- Motion and reduced-motion behavior.
- Offline or partial-data behavior.
- Instrumentation events.
- Undo, rollback, and recovery.
“Something went wrong” in a payment flow is a trust disaster. “Something went wrong” in a settings page is mildly annoying.
A translation-tax audit
Choose a recent feature:
0 of 6 done
