A case study from Prerender.io. One feature, three repositories, and the four things that had to be true before any of it worked. In April I wrote about what happens after a design sprint when you have Claude Code: four prototypes in two weeks, real business logic, mock data, flows you could click through. A few things remained open: Do they turn into production code? Or shall we throw them away...
I ran an experiment. I briefed Claude to act as a UX researcher and conduct an in-depth interview with a usability testing component, then set up other agents as client personas: different emotional temperaments, various levels of technical knowledge and attitudes toward the product. The output looked like solid research: sharp observations, specific suggestions, and well-structured transcripts...
I’ve written before about what Claude Code gets wrong: mock data that drifts, features nobody asked for, scope that expands when you’re not looking. But after several weeks of building prototypes and design systems, the patterns that worried me most weren’t the AI’s. They were mine. The quick loop Ask Claude to build something. Review the preview. Adjust. Ask again. The...
This post builds on the project template I use for Claude Code builds. Three design sprint sessions. Problem framing, concept selection, storyboards in Miro Boards. The usual next step is opening Figma and spending a week or two building mockups. This time I pointed Claude Code at the sprint notes and had a working prototype by the end of the day. Not a wireframe. A functional React app with...
This post builds on ideas from the Prerender.io Design System series. If you haven’t read it: Part 1 covers the tooling, Part 2 covers the wave-based build process, and Part 3 covers the collaboration lessons. This post is about what I do now, before any of that starts. Every project I’ve started with Claude Code has taught me the same thing: the first hour determines the whole day...
I’ve written about building design systems with AI and the project template I use for structuring that work. This post is about a different starting point entirely. A financial services client needed an application built. They had a polished public website with a clear visual identity: brand colours, consistent typography, spacing and shadows. Whether they had a design system documented...
There’s a take going around that AI makes everything look the same. Same hero sections, same illustrations, same rounded cards with the same gradients. You’ve seen the screenshots. The LinkedIn posts. The threads. And they’re right. If you point AI at a blank canvas and say “design me a landing page,” you’ll get something that looks like the last fifty landing...
This is Part 3 of a three-part series on building the Prerender.io Design System – a front-end foundation built with Claude Code and Figma, designed to serve as a single source of truth across all Prerender.io products. Part 1: From Figma to Front-End Without Losing Your Mind Part 2: Building the Prerender.io Design System, Wave by Wave There’s a version of this post where I tell you...
Once the workflow was in place, the next question was how to structure the actual build. You can't just point Claude at a Figma file and say "build this." Well, you can - but you won't like what comes back.
What worked was treating the whole thing like a construction project. Foundation first, then structure, then fittings. We called each phase a wave.
For quite some time I've been chasing the same idea. Design something in Figma, push it to the front-end, iterate, push back. A clean loop. No context lost. No "it looked different in Figma" conversations. Simple enough in theory. A bit of a nightmare in practice. The bigger challenge underneath it was this: I wanted a single source of truth for the front-end. One place where colours, typography...