Robby 5

Problem

We were at the start of a major platform replatform. Design velocity was the bottleneck, and Figma was a big part of why.

Designers were spending most of their time building static mockups, not thinking through interactions. The bigger issue was what Figma simply couldn't do: complex conditional flows, realistic data, multi-step user journeys. Prototyping at the fidelity the product actually needed wasn't really possible. So it mostly didn't happen.

PMs had it worse. They had ideas but no way to prototype independently. Every prototype went through a designer, which meant waiting, translating, and often losing nuance in the handoff. The team was moving slower than it needed to.

The challenge wasn't a lack of ideas. It was that the tools we had couldn't keep up with the pace we needed, and the gap between "I want to explore this" and "I have something I can show" was too wide.

Role

It started with a challenge from my manager. Another designer and I were tasked with building a prototype for a customer event entirely in Claude Code, no Figma static screens. Two weeks later we had something working, and it was fast enough that I couldn't stop thinking about what it would look like if we built the right infrastructure around it. That weekend I opened a new repo and started planning R5.

I had a working version by the end of that first weekend. Over the next two months I built on it alongside my regular design responsibilities, refining the system, adding features, and making it reliable enough for the whole team to depend on. The goal was to make that speed accessible to everyone on the team. Designers, PMs, anyone with an idea should be able to go from concept to working prototype without the usual bottlenecks. The key was giving the AI deep knowledge of how our product was actually built: the components, the design language, the rules. Anyone could use it without needing to know any of that themselves.

I knew it would be faster. I didn't expect it to be this good.

Insight

When the team took on the challenge of designing using only Claude, the speed difference was immediate and hard to ignore. Prototypes that would have taken days were happening in hours. That wasn't an incremental improvement. It made the old way feel broken.

But the more important realization came after. When PMs started showing up with rough prototypes that actually matched our design language, it was clear something bigger was happening. The speed hadn't just helped designers move faster. It had made prototyping accessible to people who had never done it before.

Those two things reinforced each other. Speed lowered the barrier enough that more people could participate. More participation validated that the speed was worth investing in. The question stopped being "is AI prototyping faster?" and became "how do we make this reliable enough for a whole team to depend on?"

"I was able to create general prototypes — mind you, very ugly — but it helped talk through the ideas with the design team. That way you could use your time and expertise to truly design."

— Elena, PM

Solution

R5 is a prototyping environment built around a simple idea: describe what you want to build, and get a working first draft back. Not a static screen. A real, interactive prototype that already uses the right components, the right tokens, the right design language.

You could scaffold something new from scratch, or duplicate a prototype a teammate had already built and extend it. Both paths started the same way: describe the problem, describe the screen, and let the AI take a first pass. The difference from just using Claude or Cursor directly was that R5 gave the AI something most tools lack. Deep knowledge of how our specific product was built. The components it could use, the layouts that were available, the rules it had to follow. It wasn't guessing at a design system. It knew ours.

Forking was one of the features that changed how the team worked together. Because prototypes were fully coded with real interactions, duplicating a teammate's work meant inheriting something genuinely useful, not just a static frame to redraw. You could grab something, extend it, and have a new direction in the time it used to take to open Figma.

"Forking was frictionless. See something a teammate built, grab it, extend it, done. What we were sharing were fully coded prototypes with real flows and transitions. That is worth a lot more to copy from."

— Adam, designer

The other thing R5 made possible was exploring multiple directions fast. Generating five versions of an idea, picking the strongest one, and moving forward. That kind of early exploration had always been too expensive in Figma to do regularly. In R5 it became part of how the team worked.

R5 did not replace design judgment. It removed the tax on using it. The thinking stayed the same. The time it took to act on that thinking got a lot shorter.

How It Works

The reason generic AI tools couldn't do what R5 did comes down to one thing: context.

When you prompt Claude or Cursor cold, the AI makes educated guesses. It might generate valid React. But it doesn't know your component names, your token values, your layout rules, or which icon means what in your specific product. The output looks plausible and breaks in practice. The gap between "AI-generated" and "actually usable" ends up being almost as much work as building from scratch.

R5 closed that gap by solving the context problem at the infrastructure level.

The first piece was consolidating where design system knowledge lived. Before R5, that knowledge was scattered across markdown docs, JSON, CSS, and hardcoded logic inside scripts. Adding a new component meant updating three or four files and hoping nothing drifted out of sync. R5 replaced all of that with a single source: a knowledge/ directory of YAML files that everything else generates from. One change, one place, everything downstream updates.

The second piece was making that knowledge queryable. R5 exposes an MCP server, a set of tools that lets an AI assistant ask questions about the design system rather than assume things about it. What icon represents this action? What layouts are available for a two-column data view? Which components belong in a detail panel? Instead of guessing, the AI can look it up. That's the difference between a model that hallucinates your design system and one that actually knows it.

The third piece was guardrails. Custom lint rules and composition checks ran against every prototype to catch violations before they became problems: hardcoded colors instead of tokens, components being imported across prototype boundaries, layout rules being ignored. The AI was fast, but it still needed constraints. R5 provided them automatically.

Outcome

The clearest measure of R5's impact was time. Prototypes that would have required engineering effort and days of coordination were happening in a single day. In one case, I built multiple variants of a new component using real customer data — something that would have been impossible in Figma and impractical to ask engineering to build just for testing. It was done in a day and went straight into a customer session.

Across the team, output increased by at least 150%. Eight people were using R5 almost daily, and the quality of what they were producing went up alongside the speed. Designers were exploring more directions earlier. PMs were showing up to design reviews with prototypes alongside their design briefs.

One of the quieter wins was a shared sample data system built into R5. Before it existed, every prototype used a different data set, which made things feel inconsistent and made it harder to compare work across the team. The updated version had a sample dataset baked in so every prototype pulled from the same source. It sounds like a small thing. It made collaborative prototyping feel coherent for the first time.

"We're now shipping real, functional code prototypes in hours instead of days, seeing at least a 150% increase in output. Between the fake datasets and Blob storage integration, there's nothing we can't prototype. Honestly, I'm not sure I'll touch Figma much anymore."

— Ryan, designer

The shift that mattered most was not just that the team moved faster. It was that more people were participating in the prototyping process at all. Design stopped being a bottleneck and became a conversation.

What I'd Do Differently

R5 worked, but building it fast meant accepting some tradeoffs.

The first was accessibility. There was still a learning curve for new users who weren't comfortable with AI tooling, and lowering that barrier earlier would have gotten more people using it sooner.

The more structural issue was how design system knowledge was stored. It ended up scattered across six different formats: markdown files, JSON, CSS, and logic hardcoded directly into scripts. Adding a new component meant updating three or four places at once. Manageable, but the kind of thing that compounds over time.

If I were building it again, everything would live in one place. A single source that everything else generates from. Change one thing, everything updates. That's the version I'm working toward now.