When we show a convincing prototype, very little of its preparation remains visible.

What appears instead is the experience as a whole. The same visual logic is present from one screen to the next. Components behave as expected, and when the layout changes, the hierarchy stays clear.

We can move through the prototype as one product, with very little left to piece together between its screens and states.

Getting that level of consistency into place by hand takes time, much of it spent around the screen: building scales, naming variables, setting up states and applying the same rules across a file.

Agentic tools can now take on much of that groundwork, once we have made the design decisions they are meant to carry.

In the process we use at Canvs, we shape the experience and set its rules, while the tools help those choices travel from the foundations into Figma and eventually into code.

That work begins well before there is a screen to prototype; let’s walk you through some of our process.

1. We begin with testing the system

Before we design the first screen, we need a foundation that can hold the interface together in Figma and continue guiding it when the work moves into code.

We have built our design guidance into Omni, an internal tool that contains grid structures, type scales, color swatches and other foundations, and lets us see the resulting system in use immediately.

Here, the system means the full set of scales and values generated from our choices. To create and test it, we:

• Choose the fonts, weights and brand colors we want to work with.

• Use Omni to generate the basic tokens and atoms, including type sizes for different resolutions and the broader color scale.

• View the full set on generic dashboard, mobile and web interfaces.

• Bring the output into Figma for further review and correction.

However, all of this still requires a designer’s judgment. During one of the examples we worked through, the darker end of an orange scale had started to look red. Seeing it applied across an interface made the drift easy to catch. Omni does not yet let us adjust individual colors directly, so we corrected the scale manually after bringing it into Figma.

Coming back to the workflow, once the necessary corrections are made, Figma contains the tokens and basic atoms we need to begin designing. We keep the component library open-ended at this point because its components should grow out of the actual screens.

The most immediate difference we’ve seen in our workflow is the time this setup takes. What took at least 3 or 4 hours manually now takes around 30 minutes of tweaking, after which we can begin designing normally with the foundations in place.

2. Components are built alongside screens

The raw scales from Omni tell us which colors are available. As we design, we give those colors more specific jobs.

A name such as primary-50 tells us where a color sits within a scale. A semantic name such as surface-card tells us where it belongs in the interface.

We currently use Claude to map the JSON from Omni to these semantic roles. Each role can have corresponding values for light and dark modes, so the colors update with the theme instead of being reassigned one by one.

However, the mapping still needs to be reviewed by a designer. A choice that works in the light theme may need adjusting once we see the same component against a dark surface.

As the screens take shape, we:

• Decide which repeating elements should become components.

• Design and name the base components ourselves.

• Use the Figma agent to create the states and variants needed for the prototype.

• Define how the components and layouts should respond when their state or size changes.

For instance, for one test, we designed the base button component ourselves, then asked the Figma agent to create its hover and tap states and add controls for showing or hiding its icons. That took us around 2 minutes.

The result still depended on the component being structured and named correctly. One small naming error could throw the generated set out of shape, so we reviewed its names, properties and states before continuing.

Components also give us a place to describe behavior. A search component, for example, can include its closed, open and typing states, along with a note explaining that it should expand toward the left.

We work through responsive behavior here too. Auto Layout and fill settings can handle straightforward changes in size, while a more complex dashboard may require us to specify its grid or the proportions between panels.

By the end of this stage, the Figma screen contains the component states and layout rules we need to carry it into the coded build.

3. We get the prototype into use as quickly as possible

At the moment, moving a screen from Figma into code is still a fairly manual process. However, it is also a direct one.

We give Claude:

• An image of the designed screen as a visual reference.

• The JSON exported from its components, or from the full frame when its structure allows.

• A direct instruction to map what it sees in the image to the supplied JSON and build the screen.

Claude can also inspect the Figma file through MCP, but that route has been much slower in our experience because it has to inspect and interpret the file repeatedly.

Supplying the relevant material ourselves gets us to a usable build faster. Auto Layout and componentization are especially important here because they give Claude a clearer account of how the screen is structured.

When the full frame has been componentized and placed in Auto Layout, we can sometimes export one composite JSON instead of sending each component separately.

In one relatively simple test, we moved from the designed screen to something we could use in under 20 minutes.

Our first aim is to get the prototype into our hands. Once we can use it, we:

• Move through the flow and find where the coded experience differs from what we intended.

• Give Claude a precise correction, naming the component and the required change.

• Add recurring interaction decisions to the project-level instructions.

• Rebuild and compare the coded output with the Figma screen.

A correction can be as specific as changing the corners on one card, adjusting the maximum width from 1,280 to 1,440 pixels or explaining how a hover state should behave.

At present, we provide this feedback as written instructions. We would eventually like to comment directly on the working prototype and send those comments across as a batch, but that part of the workflow is still being developed.

We now design the conditions that preserve fidelity

So far, this is how we have been building coded prototypes at Canvs. We expect parts of the process to change as we use it on more projects, but a usable build already gives us another place to continue the design.

The React design system behind the research library, with each TextField variant, its copy button and its props table sitting as the coded counterpart of the Figma component.

Once the prototype is running, we can work directly on how the experience behaves. When a correction applies beyond one screen, we add it to the project rules, which means the next screen begins with that decision already accounted for.

Maintaining that continuity is now part of our work as designers. We shape the experience and stay with it as it becomes usable, until we can put the prototype in front of the client team and help them experience an idea as it was intended.