Mockups to code

The problem

Proving it on one page first

Before asking anyone to change how they work, I tested the idea on Incoming Call Routing (ICR), a page due for a refactor. I built it as a working prototype in the portal's own stack, and an engineer ran it against the portal's real styles.

How I built it

1. 1
   Set the rules for turning Figma into components.

   I decide each component's tokens, states, keyboard behaviour and which existing parts it reuses. Those rules live in our AI agent guide, so AI speeds up the build while the decisions stay mine, and I review every change before it's committed.

2. 2
   Built it in the portal's own stack.

   React, Tailwind and design tokens in the engineers' own folder structure, so a component moves straight into the product. Engineers guided me on architecture where I needed it.

3. 3
   Documented every component in Storybook.

   Docs, variants and live controls for each component, kept in step with the library automatically.

4. 4
   Prototyped with the real components.

   Prototypes load the same component files engineers use, so every component change reaches every prototype.

5. 5
   Shared one repository with the engineers.

   Design and engineering review each other's pull requests.

A look inside the code

I'm not an engineer, but I work in the same code. Three excerpts, each with a plain-language note:

/*
 * StatusCard: summary tile
 *   label     Body 4 · neutral-500
 *   value     Subtitle 1 · neutral-900
 *             6px below the label
 *   subtitle  Smaller Text · neutral-500
 *             4px below the value
 * Surface fill, 8px radius, card shadow,
 * 24px padding.
 */

<StatusCard
  label="Extensions & devices"
  value="13"
  subtitle="2 awaiting a MAC"
/>

States         default, hover, focus-visible,
               active, disabled, error
Accessibility  correct roles and labels;
               keyboard operable
Breaking       never remove or rename props
change         without a new major version

Prototyping in code-ready form

Every project is delivered as a working prototype, so developers reuse what it already uses instead of translating a mockup.

The walkthrough below shows Asset Management, a single page where admins see every device in a customer's office, from internet routers to desk phones. It highlights what needs attention, such as phones that aren't set up yet, and lets admins add, replace or return equipment without leaving the page.

Design decisions on this page

Summary first

Four cards answer “what needs my attention?” before any table.

Grouped by device type

Each device type has its own section and actions, so admins never scan one long list.

Calm by default

Bulk actions appear only when rows are selected, and long lists collapse behind “Show more”.

What it changed in the library

Asset Management

Its dense tables drove a pinned actions column, responsive pagination and five new components for every page. Before handoff, I checked it against the library rules with AI's help.

Consistency check

Z-index values had drifted from 1 to 9999. One shared scale of layer tokens replaced them, and toasts stopped hiding behind dialogs in every prototype at once.

Engineers extend it

Engineers contributed a server-driven searchable select, a row actions menu and a tooltip refactor, all through reviewed pull requests.

A live library, not a one-time handoff

The library evolves with every project. Nothing is handed over once and frozen; work loops between design and engineering:

1. 1
   I design a feature as a prototype on the library.
2. 2
   Engineers build the real page from it.

   They add the data, logic and tests.

3. 3
   The finished page comes back to the design repository.

   On demo data, I refine its look and layout.

4. 4
   Engineers review my changes and pull them into the product.

   The portal's own tests run before anything ships.

5. 5
   New and improved components go out as a library release.

   Every page that uses them updates.

Quality built in

Accessibility

Every component covers keyboard focus and labels; dialogs close with Escape and announce themselves to screen readers. Storybook's accessibility checker flags contrast and labelling issues as I work.

Testing

Before handoff, an automated check opens every prototype and product page and fails on errors or blank screens. The portal's own tests run before my edits reach the product.

Decisions and trade-offs

The engineers' stack, not a design tool's

Learning their conventions took time and guidance, but it removed the rebuild step entirely.

Prototypes without a build step

They load slower than the product, but anyone on the team can open or edit one in a browser.

A clear line between design and logic

I own look, layout and components; engineers own data, logic, tests and releases. When a change needs their side, I write it up instead of working around it.

Result

• 50%less development time (engineers' estimate)
• 3.5×faster design reviews on average
• 2 weeksto build the core library after the pilot
• 39components in the library
• 15code-ready prototypes delivered

Consistent by default

Prototypes and the product share one set of components, so a fix made once reaches every page.

A new role

I moved from handing over mockups to working inside the product's code, with engineers as day-to-day collaborators.

What I learned

Moving fidelity from the mockup into the component made quality something the whole team can enforce.

• A small pilot convinced engineering more than a presentation could have: they saw it working on a real page.
• Clear rules make AI useful: it speeds up execution, while judgment calls stay with me and the engineers.
• What I'd do differently: start with tokens on day one. The pilot's hard-coded values were the first thing we undid.

What's next

• Move more legacy screens onto the library, one page at a time, the way the pilot started.
• Take on more front-end work as the library matures, with guidance from our engineers.