AI-assisted prototyping

Static designs couldn’t show a product made of changing state

Render’s dashboard is a control plane for infrastructure. The features that matter most are the ones where state changes over time, like a deploy moving through build and release steps, or a network rule being checked across three layers. A mockup shows one frame of that, and a Figma prototype shows a scripted path through a few frames. Neither shows what happens when someone clicks the thing that wasn’t in the script.

New product work was aligned through written product specs, and it’s harder to get excited about a new direction from a written document. When a colleague demoed a working prototype of a log explorer, the reaction was different, because people could use the idea instead of reading about it. My manager pointed to that demo as what a product vision should look like.

By early 2025, AI coding tools had made working prototypes cheap enough to try, even if the quality was lacking. I took this as a chance to experiment in a “Maker Week” project, Render’s version of a hackathon, and attempted to build several small UX improvements. I worked on it with an engineer and our Head of Design, then turned that experiment into a repeatable practice for the design team.

Choosing where prototypes live and what they’re for

Prototype inside the real codebase

During Maker Week we had two options: build prototypes inside the real dashboard codebase against our staging environment, or build a separate prototyping playground with the design system and mock data. I had sketched the playground as the initial direction, so designers wouldn’t need to run a developer’s full cluster setup.

We chose the real codebase, because a one-line command to run the dashboard repo against staging already existed and a playground meant maintaining a second component library. Hosted AI builders were out too, since they had the same maintenance burden and deploy to platforms that might compete with Render. That practical choice gave us real components, real data shapes, and prototypes engineers could read as a reference.

Work from wireframes, not from a prompt

Generating a whole screen from a sentence didn’t work well. My first attempt during Maker Week would have been quicker in Figma, and in a later test of three approaches for the same prototype, the two that started from a prompt were buggy and hard to follow. The one that worked started from wireframes, faked the backend, and built up in small steps. I came to treat the coding agent like a junior design partner, and asked it to describe the feature back in three sentences before writing any code. That catches a wrong idea before it gets expensive.

Keep prototypes out of production

Every prototype lives on a design branch with a draft pull request that never merges, and is labelled as not production ready. Designers prototype, and engineers own what ships. When engineering leadership later published guidelines for AI-assisted coding, they drew the same boundary from the other side.

A working URL for every idea worth reviewing

I proved the method on small UX fixes first. The first prototype for a live project featured a list of build artifacts and took about a day, much faster than working out all the logic and interactions by hand. A prototype of the redesigned Deploys page went in front of our VP of Engineering and Head of Product, was handed to engineering two months later, and an engineer then shipped part of its layout.

It still wasn’t perfect, but I documented my findings and created a guide for other non-technical users and a script that deploys any design branch to its own static site and staging URL on Render from a template service. I also created a starter file of instructions for various coding agents, and hosted an onboarding session for the design team. Another designer followed the guide live during that session, and I fixed the script as they hit problems and bugs. Their first prototype deployed that afternoon, and a PM later called it the north star for their engineering work.

Some prototypes are deliberately unstyled. When trying to experiment with various designs to improve network rule evaluation chains, I dropped Render’s theme entirely so feedback would be about whether the model made sense rather than perfect UI. When the coding agent kept getting basic components wrong, the cause was the same gap a new hire would hit: an undocumented design system.

After working with an agent to teach it the correct dashboard behaviour, I wrote the dashboard’s design conventions into a skill the agent reads, and with an engineer, moved it into the dashboard repository so it shapes the code other agents write. I also worked on skills that agents can run to document components using a common template so that human users and agents could develop a shared set of documentation over time.

Reviews moved onto the prototype, and Figma became the spec

Over about a year, roughly a dozen prototypes across five projects went through the process, and at least four people on the design team have been onboarded to it. Leadership reviews now happen on a working prototype rather than a mockup, and prototypes have led to real decisions.

Importantly, it didn’t replace Figma. It replaced the Figma prototype. Prototypes aren’t pixel perfect, so Figma stays the handoff specification, and keeping the two in sync is now the slowest step. Customers can’t use these prototypes because staging sits behind a VPN, so concept testing with customers either still requires a walkthrough or happens in Figma. Adoption is uneven since there’s a range of experience with these tools. One designer uses this process heavily, one uses it in part, and one finds it slower than designing by hand, or prefers different tools.

The lesson I’d carry forward is that a coding agent runs into the same problems a new teammate does. Documenting the design system for the agent made it easier for the next person too. Good, documented patterns and components remain the building blocks that help improve the efficiency of designers and agents alike. There’s no measure of the time it saves yet, and that’s something I’d want to start measuring.

For now, the main barrier to entry remains the initial setup and making these prototypes accessible externally for testing. Since we handle a significant amount of sensitive data for our customers, we need to be careful with how we approach this capability, but it’s been exciting to get closer to the experience customers will actually use.