UX Designer
Design in your tool. Frame your intent. Let the agent implement it. Validate in Storybook.
What Changes, What Doesn't
You still own the experience. What changes is that the distance between your design intent and working code has collapsed — the agent implements from your design context, referencing the production design system and component library, so what gets built actually resembles what you designed. Your validation role intensifies, not shrinks: instead of reviewing a Figma mockup and hoping engineering interprets it correctly, you review the actual rendered component against your design intent in Storybook.
The boundary between design work and implementation work blurs — that's a feature. What doesn't change is that the designer is accountable for the experience being right. The agent generates; you validate. You are not removed from the process. The interpretation gap between your design and what engineering builds is.
Design → Agent → Storybook
Design as you normally would. The workflow doesn't change how you design — it changes what happens after you design. Finalize the component or screen you want to implement.
You decide: When the design is ready for implementation — the same judgment call it's always been.
Copy the frame URL or export the relevant design artifact. Right-click the frame or component in Figma, select "Copy link to selection," and the URL contains the node-id that tells the agent exactly which frame to read. The more specific the reference — the exact frame, at the right fidelity — the better the implementation.
If the Figma MCP is configured with Dev Mode active, you can instead ask the agent to "implement my current Figma selection" without copying a URL at all.
Frame your intent in language the agent can act on. Reference the design, describe the component's states, specify any constraints.
"Implement the Notification Banner component from [frame URL]. Match the design system typography and spacing."
"Generate the error state for the login form based on [frame URL]. The error message appears below the field, not above."
"Implement the nav component for mobile. The collapsed state uses a hamburger at 768px and below."The agent reads the frame's layout, colors, typography, spacing, and layer structure via the Figma MCP. It generates a component file and a styles file, maps Figma styles to the project's design tokens where possible, and places the files in src/components/ following the project's naming conventions.
The agent handles: Code generation, design system pattern matching, component structure, responsive behavior.
You don't need to read the code to review it — that's what Storybook is for. But a quick scan for structural issues (is the component organized the way you expected? are the named states correct?) catches problems before full validation.
You add: Judgment about whether the code structure reflects the design intent, even before visual validation.
Open Storybook and navigate to the component. Check every state: default, hover, active, error, loading, disabled — whatever applies. Compare what you see to your design. This is visual proof, not code review.
You add: The judgment call about whether this matches. The agent generates; you validate. No one else can make this call — it requires understanding the design intent.
When something doesn't match, describe the gap and ask the agent to revise. Be specific: "The spacing between the icon and label is 8px in the design, not 12px" produces faster results than "the spacing looks off." The loop between design, agent, and Storybook is fast — don't try to get it perfect in one pass.
"The [element] in the [state] state doesn't match the design. In the design, [specific description of intended behavior]. Update accordingly."If the design itself needs to change, update the frame in Figma and ask the agent to regenerate: "The design has been updated at [URL] — regenerate the component." The agent diffs the changes and updates only the relevant files.
When Storybook validation passes and you're satisfied the implementation matches the design intent, mark the component ready. This is the signal that engineering can proceed — your accountability for the experience is fulfilled at this point.
Designing for Better Agent Output
No changes to the Figma workflow are required — the agent reads whatever is there. But a few practices consistently improve output quality, because they give the agent cleaner signals to work from. These aren't new Figma practices — they're good design hygiene that happens to make translation dramatically more accurate.
The agent reads layout direction, gap, padding, and alignment from Auto Layout properties and maps them directly to CSS flexbox. A component built with Auto Layout produces code with display: flex, gap, and padding values that match your design. A component laid out with manual positioning produces hardcoded top and left values that don't adapt to content or viewport changes. Auto Layout is good design practice — it also happens to be the format the agent translates most accurately.
Layer names become class names and prop names in generated code. A layer named Button / Primary / Large produces a component with a variant="primary" prop and a size="large" prop. A layer named Frame 47 produces frame47. The agent uses what it's given — descriptive layer names translate to self-documenting code that engineers can read and maintain without reverse-engineering what each element represents.
When the Figma file uses a published color style or variable — for example, a color named color/text/primary tied to a specific hex value — the agent can map that to the project's design token of the same name rather than hardcoding the hex value. This is the difference between a component that respects your design system and one that has dozens of hardcoded values that break when the design system changes. If the file uses raw hex values, the agent will output raw hex values.
Asking the agent to implement a full page in one shot usually produces messy output — the scope is too large to translate cleanly. Design individual components (a card, a banner, a form field) and implement each one separately, then compose them in Storybook. Smaller scope means cleaner output, easier validation, and faster iteration. Each component can also be handed to engineering independently as it's validated, rather than holding everything until the full page is ready.
Figma's Code Connect maps Figma components to their production code counterparts. When a component already exists in Storybook and Code Connect is configured, clicking on a Figma component surfaces the live code — prop names, accepted values, usage examples. Before asking the agent to implement a component, check whether it already exists. If it does, your work is aligning the Figma component to the existing code (updating props, syncing design tokens), not generating new code from scratch. For recurring components — buttons, form inputs, navigation elements — Code Connect also makes drift visible: you can see exactly where the current production component diverges from the design, and target only those gaps rather than regenerating the whole component and creating unnecessary churn.
Storybook as Validation
Storybook is your validation environment. You don't need to understand the code — you need to understand whether the visual output matches the design. Here's what to check:
Default, hover, active, error, loading, disabled — whatever states you designed. If a state is missing from Storybook, it wasn't implemented. Ask the agent to add it.
Typography, spacing, color, border-radius, icon sizing. Compare at the pixel level if the component is UI-critical. Storybook shows the actual rendered component, not a mockup.
Resize the viewport in Storybook to check mobile and tablet breakpoints. The agent implements responsive behavior from the design system patterns — validate that it applied them correctly.
Click through the interactive controls in Storybook. If the component has hover states, transitions, or interactive behavior — exercise them. Visual proof includes behavior, not just appearance.
When you hand off a component with a Storybook story, you're handing off proof — not a spec. Engineering receives a working, tested component with every visual state documented, rather than a static mockup they interpret.
Framing Design Intent
The agent acts on specific, structured descriptions of design intent. The more precisely you describe what you want — including what state, what breakpoint, what design system constraints apply — the more accurate the output. There are five elements that consistently improve results when included together:
"Implement [component name] at [breakpoint / state].
Design reference: [frame URL or description].
Constraints: [design system token, spacing rule, accessibility requirement].
States to implement: [list each state explicitly]."Each element serves a purpose. The component name scopes what the agent generates. The breakpoint/state tells it which version of the design to implement first. The design reference gives it the visual source of truth. Constraints prevent the agent from making reasonable-but-wrong decisions — if you don't mention that a spacing value should come from a token rather than be hardcoded, the agent will choose. States to implement prevents the most common omission: only the default state gets implemented and everything else has to be added separately later.
When the agent produces something that doesn't match, describe the gap specifically. "The button label is too small" is harder to act on than "The button label should be 14px / 500 weight per the design system's button-label token." Reference design system tokens and specifications when you have them — the agent has access to the same design system context and will apply it when explicitly referenced.
For data-driven interfaces — features that will display API responses, paginated lists, or real-time updates — the agent can bridge the design-to-data gap before engineering begins integration:
"Generate realistic mock data from the [feature] API spec so I can test my layout
with data that resembles production — including edge cases like empty states,
long strings, and error responses."A Complete Design-to-Storybook Flow
Here's what the full workflow looks like in practice — from a Figma frame to a validated, handoff-ready component. The component is a notification banner with three severity variants (info, warning, error) and an optional dismiss action.
Designer: Implement the Notification Banner component at
https://figma.com/design/abc123/DS?node-id=8-42
It should support three variants: info, warning, error.
Use SCSS modules. The dismiss button is optional —
controlled by a `dismissable` prop.
Agent: [reads Figma frame, generates NotificationBanner.tsx,
NotificationBanner.module.scss, NotificationBanner.stories.tsx]
Here's what I generated. The three variants map to a `variant` prop.
Colors are pulled from the project tokens: $color-info, $color-warning,
$color-error. The dismiss button renders when dismissable={true}
and fires an onDismiss callback.
Nine stories: three variants × (with dismiss / without dismiss)
plus one for a long-message edge case.
Want me to write these files?
Designer: Yes. Also — the warning variant background in the design uses
the subtle warning token ($color-warning-subtle), not $color-warning.
The current output looks too saturated.
Agent: [updates NotificationBanner.module.scss]
Updated. The warning background now uses $color-warning-subtle (#FEF9C3).
The border and icon color still use $color-warning for contrast.
Designer: [opens Storybook, checks all nine stories]
The warning story looks right now. The error variant dismiss button
is missing the aria-label — it's just an X icon with no accessible name.
Agent: [updates NotificationBanner.tsx]
Added aria-label="Dismiss notification" to the dismiss button.
Also added role="alert" to the banner root for screen reader announcement.
Designer: Perfect. Accessibility looks clean now. Marking this as ready.
[Updates sync-manifest.json: status "ready", note "All states validated
in Storybook. Accessibility checked. Dismiss callback wired."]Total times the designer wrote CSS by hand: zero. Total times the designer opened the production app to check visual output: zero. Human effort focused on: design quality, token accuracy, accessibility review, and the approval decision.
The Storybook story file goes with the component to engineering — proof that every visual state was validated before handoff, not a spec for engineering to interpret.
Common Pitfalls
The agent implements what you describe. If you don't mention the error state, it may not implement it — or it may implement a generic one that doesn't match the design. List every state you want in your prompt.
Saying "use the card-surface color" is more durable than saying "use #1a2826." Tokens connect the component to the design system and survive theme changes. The agent knows the design system tokens — use them.
The validation step is yours. Don't mark a component ready based on a quick scan of the code — render it in Storybook and check every state you designed. That's what the tool is for.
For complex components with many states and interactions, implement one state at a time rather than requesting the entire component in one pass. Validation is easier and revisions are faster when the scope of each iteration is narrow.
Vague feedback produces vague revisions. "The spacing looks off" is not actionable. "The gap between the icon and label is 12px in the implementation; it should be 8px per the design" is. Your design eye is the asset — translate it into specific, actionable language.