Closing the Design-to-Code Loop

Role: Global Director of UX

Timeline: 2026 to Present

Sector: Legal Technology, B2B

A Claude-native design system that lets a non-coding UX team push production components and design straight into the repo.

THE CHALLENGE

Every handoff was a translation, and every translation lost something

The design system lived in Figma. Engineering consumed it by reading it and rebuilding it by hand. Every component went through that translation step, and every translation step introduced drift: a border radius here, a spacing token there, until Figma and the live product quietly stopped matching.

The solution was not to improve system documentation, but to have designers work directly within the codebase where the system operates.

MY ROLE

Co-owning the shift with Product and Engineering

As Global Director of UX I co-owned the product strategy behind this shift with our Product and Engineering directors. This was not work I went looking for. It was handed to my team as the next stage of how we build. My job was to work out how a design team with no coding background could operate inside a live repo, and to do it without breaking what the team already did well.

THE APPROACH

Working out the workflow before scaling it

Finding the right tools

We started with Figma Make for three to six months. It was strong for prototyping ideas quickly but hit a ceiling once we added real complexity. We moved to Claude Design for component work, wireframes and early exploration, and Claude Code for the repository work itself, keeping Figma for what it is still best at rather than retiring it outright.

Moving the design system out of Figma and into the repo

We rebuilt the design system as a Claude-native toolkit rather than a Figma file with documentation attached to it. It is a monorepo with two parts: a Claude Code plugin, made up of skills that teach Claude our tokens, iconography, a 29-component library and pattern rules, and a runtime component package that applications actually import. The workflow runs design in Figma or Claude, push to Claude Code, on-brand accessible React and Tailwind UI out the other end. A GETTING-STARTED file means any teammate, designer or engineer, can set up the same way rather than learning it informally from whoever got there first.

Moving from a safe visual space to the terminal

Git. Branching, pull requests, merge conflicts, the terminal. For most of the team this was new and it felt intimidating. A UX team used to working in a canvas was suddenly working in a command line. We built up our own prompts and habits so we could work consistently, and the terminal became a means to an end rather than somewhere we lived. Over time that meant less time in GitHub and more time in the Claude interface, where the team was actually comfortable thinking.

Creating a hub for our North Star and inflight work

We brought our North Star design over and used it to create a hub for in-flight projects. This came out of a real problem: Figma Make was not using our design system properly, so concepts built there looked plausible but were not actually built on our tokens. Moving that work into Claude Code fixed it. Token usage was correct from the start rather than something we had to catch and fix later. Branching let us run several concepts at once without them interfering with each other, merging to main only once a concept had been tested. And because each branch can be shared as a public link, stakeholders and testers see something close to the real product, not a static mockup standing in for it.

Building in governance

Working in a live repo meant we needed the same discipline any engineering team has, not a design-team exception to it. We set up a PR approval process with review requests posted straight into Teams, so nothing merges without a named reviewer seeing it. We built skills specifically to hold the design system in line, checking that new work follows it rather than drifting from it component by component. And we run a weekly report comparing hardcoded components against design-system components, which gives us an honest, ongoing read on whether the system is being used or being worked around.

HOW WE ARE MEASURING IT

The measurement framework went in at phase one

What is already in place is the instrumentation to judge it

  • Coverage and drift. A weekly report comparing hardcoded components against design-system components, so compliance is something we watch trending rather than guess at.

  • Handoff efficiency. Time from design decision to shipped component, and how many translation steps disappear.

  • Team behaviour. A shared Miro board logging efficiencies as the team finds them, with learning and example prompts shared in Teams so improvements do not stay with one person.

  • Governance and risk. We build for regulated clients, so the test is whether PR review and the design-system skills hold up to the same scrutiny our existing process does.

WHAT MADE IT WORK SO FAR

Key Learnings

The terminal was the real barrier, not the concept

The idea of designers working in code was not the hard part. Git, branching and the terminal were. The team needed dedicated time and repeatable prompts to get comfortable, not just a tool switch.

Prompting had to become a shared asset, not an individual habit

Working well in Claude Code turned out to be its own skill, and it was not obvious to everyone at once. We built a prompt library on Miro and started sharing examples in Teams so what one person learned stopped being one person's advantage. That is now as much a part of onboarding as the tooling itself.

Keep the tool that is still the best tool

Retiring Figma Make in favour of Claude Design was not a wholesale rejection of Figma. We kept it for wireframes and early exploration. The lesson was choosing tools by what they are actually good at, not by loyalty to a single workflow.