AI-native workflow

Removing the translation layer between design and code

  • Process design
  • Prototyping
  • Design systems
  • Team enablement
  • 2026
A white pill button labelled Button at the centre of a dark navy frame, linked by a thin gradient line to three panes: Paper, where the button is selected with its variant and fill token shown; Button.astro, where the variant line of the code is highlighted; and Live, where the button sits in a sketch of a page. In the loop, changing the variant in one place changes it everywhere.

I redesigned how Socialive moves from design to working software. Using Claude and Paper, I connected prototyping and implementation in one workflow, cutting prototype creation from days to minutes and reducing the path from approved design to shipped code from weeks to a single day.

Team
UI/UX designer, UI design engineer, two front-end engineers
Timeline
2026–present
Outcome
A connected design-to-code workflow adopted across design and engineering, accelerating iteration and reducing handoff overhead.

The bottleneck

Our process separated design from implementation. Designers created static mockups in Figma, then engineers rebuilt them by hand. Each handoff introduced delays, discrepancies, and rework.

A testable prototype took days. Most features went through only one to three rounds of iteration. Stakeholder decisions took weeks.

The problem wasn’t how fast we designed. It was how much work stood between an idea and something people could evaluate.

A timeline of the old process on dark navy: Idea, then days to a static mockup designed in Figma, then weeks to a stakeholder decision reviewed as static screens, then weeks to shipped code rebuilt by hand. Three handoffs are labelled along the line, and a dashed arc from shipped code back to the mockup is marked one to three rounds of rework.
The old path from idea to shipped code: three handoffs, weeks between decisions, and rework looping back to the mockup.

From mockups to working prototypes

I moved prototyping into code, using Claude as a building partner. Instead of presenting static screens, I could create working experiences that stakeholders could click through and evaluate.

This changed what we could test and how quickly we could learn. Product behavior, interaction details, and edge cases became tangible before engineering committed to implementation.

Catalyst’s first prototype was built this way. The workflow soon became a repeatable approach, supported by shared wireframe conventions, realistic data, clearly marked demo-only controls, and visual QA after each change.

The Catalyst prototype: a dashboard with a prompt box, recent videos and a sidebar, inside a browser-like frame.
The live Catalyst prototype, built in code. Click around: on a phone it shows the mobile layout.

Connecting design and code

Prototyping in code made exploration faster, but created another problem: Design files drifted from the product as implementation moved forward.

I looked for a way to keep design and code connected. I prioritized a design tool built on HTML and CSS, so there’s no translation layer between design and code, and chose Paper. I connected it to Claude through Paper’s MCP server.

The result was a bidirectional workflow. Designs could inform code, and code changes could flow back into the design canvas. Shared styles, tokens, and components keep design and code consistent and reduce rework.

The workflow now supports both marketing and product. Website updates can ship directly. Product changes still go through engineering review and QA.

The Catalyst 2.0 design file in Paper: a Buttons page showing six variants in every state, with the primary button selected. The property panel on the right shows its height of 40, padding of 16, gap of 8, a radius of 999, and a fill bound to the token dark-action-primary with text bound to dark-text-inverse.
The primary button selected on the Paper canvas. Its fill and text are tokens, and the panel shows the rest of its values.
Button.astro in a dark code editor: the primary variant's background and color use the tokens color-dark-action-primary-default and color-dark-text-inverse, and the base button sets a height of 40px, padding from spacing-16, gap from spacing-8, a full radius and body text size, with each matching line labelled fill, text, height, padding, gap, radius and label. A preview pane shows the rendered button.
The same button in Button.astro: the same tokens and values, and the button they render.

Changing how the team builds

Introducing a new workflow required more than choosing tools. Engineering was initially hesitant, so I focused on demonstrating the results through real work rather than trying to sell the idea.

As the process proved itself, adoption grew. Two front-end engineers now use the workflow alongside our UI/UX designer and UI design engineer.

The shift reduces manual translation and gives developers more time to focus on complex engineering problems. It also creates more room for iteration before work reaches production.

The goal wasn’t to bypass engineering. It was to remove work that added little value while preserving the review and quality controls that production software requires.

The same timeline as the old process, now on a gradient from cyan to violet: Idea, then minutes to a working prototype built in code with Claude, then one day to a stakeholder decision tested as a real experience, then one to two days to shipped code using the same tokens as the design. The steps are labelled built with Claude, click through and decide, and reviewed by engineering, and a dashed arc back to the prototype is marked ten or more rounds of iteration.
The path today: a working prototype in minutes, a decision in a day, shipped code in one to two days, and iteration where the rework used to be.

The right tool for the work

Not every design task belongs in code. Figma remains useful for nuanced visual exploration and work that needs a high degree of craft.

This isn’t about replacing every tool. It’s about eliminating unnecessary translation wherever design and code can share the same foundation.

Three columns on dark navy, each with a tool icon above a label. Claude for wireframes and flows, clickable flows built in real code. Claude plus Paper for design system to code, tokens and components that ship. Figma for visual craft, refined graphics and fine detail. A bracket joins all three to a line beneath reading Human in the loop: a designer reviews and approves every output.
Each kind of work gets its tool: Claude for flows, Claude with Paper for the design system and code, Figma for visual craft, and a designer reviewing every output.

Impact and what’s next

  • Days to minutes: Time to create a testable prototype.
  • 1–3 to 10+ iterations: More opportunities to refine features before implementation.
  • Weeks to one day: Time from design to stakeholder decision.
  • Weeks to 1–2 days: Time from approved design to shipped code.
  • Adopted across design and engineering: The workflow supports both website updates and product development, with engineering review and QA retained for product releases.

The result is more than faster prototyping. It’s a shorter path from idea to decision to delivery, with less manual translation and more time spent improving the product.

Next: Extend the workflow into AI-assisted processes that help the team maintain, improve, and ship updates with less manual work.