Design to Code was already happening at Stepstone. Designers were using Claude Code and Figma to generate coded prototypes, and it worked. The problem was it only worked if you knew the right people, had the right access, and could figure out the setup yourself. My job was to build the system around the workflow so it could scale.
With Claude Code, Figma, and our MCP setup, a designer could take a layout and generate a coded prototype aligned to Genesis. Some designers were already doing it. But the experience was fragmented.
Getting started meant figuring out a lot yourself: local tooling, repo access, package permissions, which version of what to install. Support happened through individual DMs. There was no shared environment for publishing or reviewing prototype work. Updates to Claude Skills and packages weren't automatic.
The tool worked. The system around it didn't.
Each time a new designer tried it, they were starting almost from scratch. That's fine for early adopters who are motivated enough to push through. It doesn't work for a design organisation trying to use something consistently.
I focused on the operational side. Not the prototyping itself, but everything that needs to exist around it for the workflow to be reliable, teachable, and sustainable at scale.
This meant looking at every step a designer would take from Figma to a published prototype, identifying what could break, and working out what needed to be in place before a wider rollout made sense.
Figma layouts don't always map cleanly to code. Designers can structure things visually in ways that work on screen but produce messy output when Claude tries to interpret them. Without shared guidance, every designer was approaching it differently.
Defining the layout primitives and composition patterns that translate well into code. This meant thinking about Figma not just as a design surface but as the starting point for a coded structure. Flex, spacing, wrapping, constraints, component composition: all need to be clear enough for MCP and Claude to interpret reliably.
There was no shared place for designers to publish, review, and compare coded prototype work. Each designer was working in isolation, with no consistent environment and no easy way to share what they'd built internally.
Proposing a shared Design Storybook, protected through OKTA and structured by domain. This gives the team a single place to publish prototype work without everyone building their own setup. I also worked on validating whether designers should use terminal-only or VS Code, and why.
Setup was too dependent on knowing someone. Access requirements for repos, packages, Storybook, and Claude weren't documented or resolved before designers tried to get started. Day-one blockers were common.
Mapping every access requirement before rollout: Stash, Bitbucket, repos, packages, Storybook, Claude, and anything MCP-related. Then defining the approach for onboarding documentation: not a rough guide, but Playbook-quality steps that a designer can follow without needing to find someone to ask.
Support was running through personal DMs. That doesn't scale and it creates hidden dependency on individual people. Package and Claude Skills updates were also manual, meaning the workflow would silently become outdated.
Moving support to a shared Genesis Slack channel, so answers are visible to everyone, recurring issues surface naturally, and knowledge isn't locked with one person. And identifying the need for automatic update handling for packages and Claude Skills, so the workflow stays current without maintenance overhead.
For Design to Code to be genuinely useful, designers need to share prototypes internally through accessible links. That's harder than it sounds: it touches security, hosting infrastructure, access control, and governance.
Surfacing this as a key open question that needs technical partnership. It can't be resolved by the design team alone, but it's one of the most important things for the workflow to feel complete. Leaving it unresolved means prototypes stay local and aren't easily shareable.
The project is still in progress. But the work has already shifted the conversation. The question is no longer "can designers generate code?" It's "what does the system around that need to look like?"
Current outputs:
Design to Code is often talked about as a tooling story. It isn't. The tool is the easy part.
The hard part is creating the conditions for a whole design organisation to use a workflow consistently: the right Figma approach, the right environment, the right documentation, the right support model, and the right update mechanism. Without those things, you end up with a powerful capability that only a handful of people can actually access.
The goal was not to turn designers into engineers. It was to give them a safer, more structured way to build, test, and share realistic product experiences.