From mouse-pointer to prompts
When the opportunity arose recently to establish a new code-first workflow from the ground-up, we jumped at it. This was a true greenfields project i.e. a blank canvas with no existing codebase or design system to work around, and the first time we'd been able to apply this kind of approach to an actual project. We'd experimented with a number of vibe coding tools before, but there's a difference between exploring a concept and committing it to something more real.
The core idea was straightforward: instead of spending hours building wireframes and high-fidelity Figma mockups, we'd use Claude Code to generate working React prototypes directly in the browser. Describe what you want, iterate in real time, show stakeholders something they can click through, and hand off code that a developer can pick up and run with.
Getting started does take some adjustment: becoming comfortable in the terminal, structuring prompts effectively, setting up a repository and branching files to explore different directions. But it's largely a one-time cost, and once the new way of working clicks, the pace changes considerably. And now that Claude has a dedicated Code tab in their app, that initial barrier is lower than it was for us, which will matter if this scales beyond a small group of designers.
What doesn't change is the thinking that underpins good design. You still need to understand the problem, who you're solving it for, and why one approach is better than another. As a colleague put it: "It's a different way of visualising your intent, not a replacement for having one."
What actually got better
The most immediate win was prototype fidelity. A highly detailed interactive prototype surfaces things that static screens or Figma prototypes (even really good ones) simply can't, especially when the domain you're building in is very complex and nuanced. Intricate behaviours, detailed micro-interactions, dynamic data, edge cases and flows that seem logical on paper but fall apart when someone's actually using them, can all be visualised in literally minutes. The complexity we've been able to reach with this process proved far more useful in aiding decision-making within the wider product team than anything we could have produced in Figma. Branching is also more fluid in practice than we found with Figma. Need to explore a different direction? Branch. Want to preserve the current state before a risky change? Branch. It's a small thing but it adds up over the course of a project. Additionally, once a solid code-based design system is in place, the jump from wireframes to something more polished also speeds up a lot.
Where the time is now spent
If you've tried any of the many natural-language coding services out there, you'll know that output quality is often prompt-dependent. Some things come out right on the first attempt, others take a few passes (and then some) to get there. Becoming a good prompter is a genuine skill that takes time to develop and at the moment that learning curve is part of the deal for us. The gap between "good enough to show" and "exactly right" still takes real effort to close and experience, design judgment and craft still matter a lot.
What about Figma?
We haven't left it behind entirely, but the time spent in the app and the use case for it has changed significantly. For most of this project, iterating directly in Claude Code was simply faster and more useful. That said, some early Figma exploration did prove valuable, not as a deliverable, but as a way of building an initial mental model before writing a single prompt. Going forward, whether that kind of early thinking needs to happen in Figma specifically, or on a whiteboard, or just on paper, is an open question. The tool matters less than the thinking.
What we're now figuring out?
While this feels like it could extend well beyond greenfields projects and potentially become a new foundation for how Purple Shirt engages with our clients on design projects, there are a few open questions still kicking around. How much dev support this approach eliminates, how to best create robust design documentation, what the most optimal GitHub setup looks like, and where to set up merging checkpoints along the way are all things we will be continuing to work through.
Working in this way and at this pace also uses a lot of energy and tokens, so as this scales, being intentional about getting further with fewer tokens will matter, both from a cost and sustainability perspective.
The experiment is ongoing, and our thinking will keep evolving as it does.
