Andy WilsonThis one is still in progress. Flat designs were losing detail on the way to engineering, and AI was changing what designers could build, so I’ve started moving my design team at Whitespace to a workflow where design, prototype and handoff come from the same piece of work. We use Claude Code connected to Figma and our design system. Concept-to-prototype time has dropped from days to hours. The people side has been harder, and it’s still going on.
Why I made the shift
I spent six years as a frontend developer before moving into design, so I’ve seen the handoff between the two from both sides. For a long time it was where quality got lost.
What was built often didn’t match what we designed closely enough. Flat designs can’t carry everything. They don’t show how an interaction behaves or how a feature should really work, so developers fill the gaps themselves. Designers, meanwhile, didn’t always understand what the code could do, or how their decisions affected what was built.
We tried to close that gap with Figma prototypes, but they kept breaking. Our application has a lot of functionality, and there was too much to hold together in a click-through prototype.
Then AI made it possible for designers to build working prototypes themselves, and they held up far better than anything we’d made in Figma because they behave like the real application. The line between frontend developer and designer started blurring quickly, and I wanted us to change how we work while it did.
What we changed
We’ve built Claude Code into our workflow, connected to Figma through MCP. Because it works with our design system, a designer can produce flat visuals quickly and come away with a working prototype as well.
We use those prototypes to present ideas internally and to customers. Developers use them as a much clearer reference when building in our Angular frontend, and they show interactions a static design can’t.
Before, design, prototyping and handoff were separate steps, and detail was lost between each one. Now they come from the same piece of work.
Bringing the team with me
The team’s response has been mixed. Some designers jumped in straight away. Others found the technical side confusing, or felt unsettled by moving away from ways of working they’d spent years getting good at.
Underneath that is a real anxiety. Nobody knows exactly what design work will look like in a few years, and there’s a fear that not adapting could cost people their jobs. I didn’t want to dismiss that, and I didn’t want to make it worse by pushing too hard.
My developer background helps most here. I can explain git and the commands the team needs without it feeling like a lecture. I’ve written guides, and I’m building a Claude module that translates engineering language into plain terms, so designers can ask questions without feeling exposed.
I’m also careful about pace. People get time to absorb each step, and nobody is pushed too far outside what they’re comfortable with. I share what other people in the industry are doing with AI, especially designers, so the team can see this is where the field is going and not just my idea.
How it’s landing
Developers and QA have responded best. They’re working with AI in similar ways, so working prototypes make immediate sense to them, and the handoff is clearer.
Colleagues further from the code are more cautious about what it means for how we work, and in a regulated industry there are limits on how fast things can move. Part of my job is keeping the team in step with the industry while respecting the boundaries the business sets, and building confidence one example at a time.
Where this is heading
I’ve never fitted neatly into one role. I was a developer who cared about design, then a designer who still thinks in code. I think the gap between the two will largely close. Frontend developers will focus more on implementation, and designers on how things look, feel and behave, but we’ll be working on the same thing.
Over the next six months, I expect AI to be part of every design workflow on the team, with Figma and our design system still at the centre. Within a year, I’d like designers to be contributing directly to the product codebase, committing work on branches that developers can review and merge. For that to happen, the business will need to trust designers to add value in code even when they don’t understand every line, the same way we already trust developers to make sensible design decisions.