From design intent to working code
I lead the UX workstream behind a new way of building product: rather than treating a Figma handoff as the final design specification, designers create working front-end implementations using the real design system. That code submission becomes a shared specification for Product, Engineering and QA.
The goal is not to turn designers into software engineers, or to replace Figma. It is to remove the translation gap between a validated design and the software customers use.
The situation
The traditional handoff model had a familiar weakness. Designers would create and validate work in Figma; engineers would interpret it and rebuild it in production code. The translation introduced ambiguity, rework and visual drift. Missing states could surface late in QA.
AI-assisted development makes it possible to shorten that gap - but only if UX can provide reliable, system-grounded context rather than screenshots and prose alone.
The third changes the relationship: the prototype is no longer a separate truth that Engineering needs to translate.
Designers draw.
Developers interpret.
Figma files and redlines make intent visible, but drift can begin at handoff.
SpecificationDesigners explore faster.
Developers still rebuild.
AI accelerates exploration, but the prototype remains separate from production.
Separate prototypeUX ships design with code.
Engineering ships the product.
The system-grounded code submission becomes the handshake between disciplines.
Shared artefactThe operating model
owns now.
The role changes shape: from producing a handoff to establishing the context, artefact and gate that carry design intent into delivery.
Operating model · schematicMachine-readable system knowledge
components / states
tokens / constraints
safe mock dataA working specification
System · fidelity · accessibility
Figma remains the space for design
Figma remains the place for exploration, user testing, iteration and the design-system source of truth. The change comes after a direction is approved.
The system becomes a substrate for generation
We turn Storybook documentation, Figma libraries, design decisions and component conventions into structured, versioned knowledge. Usage rules, props, states, composition patterns and anti-patterns become retrievable context for AI, so generation starts from the real system rather than a visual approximation.
A prerequisite, not a prompt trick
The operating model makes Figma-to-React alignment explicit: component names and structure need to agree. A plausible-looking screen is not sufficient; the implementation needs to use the actual system. Every component and convention captured also improves the context available to the next piece of work.
UX ships a working front end
UX uses AI-assisted tooling to create a working front-end implementation with real components, tokens, key states and safe mock data. Design with code. It lives in a UX-owned repository as a code submission. Product and UX co-author the story and acceptance criteria; Engineering adds business logic, state management and integrations.
This does not require designers to become software engineers. The skill shift is towards directing AI, judging the implementation and knowing what to reject: the designer remains accountable for the experience while AI helps produce the code.
A different agreement with Product and Engineering
UX and the Product Owner co-create the story around the front-end code submission, feature description and acceptance criteria. Engineering consumes that context and connects the interface to production data and behaviour. The responsibility for business logic, APIs and state management remains explicit.
That separation makes the artefact useful: the UX front end defines what design system components to use, and the intended experience, without pretending that mock data is a finished product. It also plugs into the existing engineering workflow rather than creating a parallel UX toolchain.
Quality becomes a shared gate
The pipeline includes an explicit UX review alongside QA and Product approval. UX checks system compliance, design fidelity and accessibility before release.
The code submission is the handshake: Engineering receives an executable expression of intent, then the disciplines validate the integrated result together.
- 01ExploreFigma and research
- 02GenerateAI + system knowledge
- 03SpecifyUX code submission + story
- 04IntegrateEngineering implementation
- 05GateQA + UX + Product
- 06ReleaseProduction
The challenge after generation
Faster code changes the review problem. The programme discussions highlight a practical tension: Product and UX need visibility into meaningful changes without becoming a manual bottleneck for every release.
The work therefore includes how to identify impactful changes, communicate release intent and route attention to the right reviewers. A quality gate needs an operating rhythm, ownership and useful context to function at delivery speed.
What changes
| Before | After |
|---|---|
| Figma was the final handoff artefact. | A working front end becomes the shared specification. |
| Developers translated designs into code. | UX supplies a system-grounded UI implementation; Engineering focuses on functional integration. |
| Design-system knowledge was primarily for people to interpret. | Components, tokens, states and constraints also ground AI-assisted generation. |
| Drift was often discovered downstream. | UX review checks fidelity and accessibility in the delivery pipeline. |
The programme moves the team's deliverable towards working front-end code submissions, supported by AI-readable design-system documentation and an explicit UX review in the delivery pipeline. I co-lead the programme with Engineering and have presented the approach to the executive team.
The result I can explain most clearly is the change in ownership: UX carries design intent into an executable artefact, while Engineering integrates it into the product and quality is reviewed together.
Current status: Grissino is a live pilot. The operating model is in use, but speed and quality impact will be assessed after complete delivery cycles rather than presented here as established results.
What I’m learning
AI does not remove the need for design systems or design judgment. It increases their importance. AI can accelerate the wrong thing with remarkable efficiency when its context is vague, inconsistent or disconnected from the production system.
The technology is valuable because the organisation gives it a reliable place to operate: clear ownership, trustworthy documentation, a shared artefact and a quality gate.