In physical product design, the first time a design becomes something we can hold is often the first time we understand what we have actually made.

Until then, the object exists in drawings, renderings and perhaps a very convincing model on a screen. While these can settle its form, they cannot tell us how its weight will sit in the hand or how a control will feel when it moves.

Prototypes used in industrial design, textile design and other physical disciplines let us experience a concept and judge whether it holds up in use for the people it is intended to serve.

Digital products, on the other hand, have a physicality and a tangibility that are very unique to their use. Essentially, their ‘feel’ comes through in the way a product responds, how it moves and what happens during the moments when somebody has to wait.

Static screens have given way to high-fidelity simulation

So far, static screens have served us well as prototypes precisely because the product and the material we use to design it are both digital. Put a static screen on a phone it’s designed for, and it may already look faithful enough to judge.

However, the behavior connecting one screen to the next still lives in the designer’s head, and has to be explained for the intended experience to come through.

Figma click-throughs can make some of this behavior visible, but only along the routes and states we link together. Someone still has to operate the click-through, and anything outside those paths still has to be explained.

Carrying the fuller experience into code has generally required a separate, time-intensive build, which is why any such prototyping has remained in Figma.

Today, however, as agentic workflows stand, designers can prototype anything from a single interaction to a complete product flow in code. With the right groundwork, they can do this quickly enough alongside work on an open brief or even a live project.

Once the intended experience can be coded at this speed, the standard for a prototype has to move with it. Wireframes are useful for while we’re thinking through an idea, but they can no longer do the whole job of the artifact we put in front of a client.

At Canvs, that means pushing ultra-high fidelity as far as reasonably possible so the prototype reproduces how the product or proposition itself is meant to feel.

Higher fidelity lets us experience the product’s behavior much earlier

Once we set that bar, fidelity has to cover the whole experience. The visual finish needs to be right, but so do the interactions, transitions and even the time the product takes to respond.

Let’s take a proposed product with an agentic chat, for instance. If its answers will take time to arrive once the product is live, the prototype should ideally reproduce that delay. The service behind the answer may still be disconnected, but we can simulate it so the prototype appears to wait and then responds as intended.

During this wait, the interface still has a job to do: it needs to show that the request has gone through and that the product is working on it.

Transitions need the same care, because the way an interface moves from one state to the next helps someone understand what changed.

Fidelity also has to cover what happens when someone takes a different route through the flow. If they go back, change an earlier choice or leave and return, the prototype should respond as the product is intended to.

Here, it is important to note that when we say ‘high fidelity’, we’re describing the experience. The prototype’s only job is that it should feel like the real deal; it does not need to be a fully coded, deployable piece.

When we place a prototype like this in the hands of clients and stakeholders, the experience no longer has to be carried by our explanation or completed in their imagination. They can encounter the design for themselves and respond to how it actually feels.

Engineering gets a more complete handoff

Pushing a coded prototype to this level of fidelity has a second benefit: it can move the handoff to engineering much further upstream.

Building an interaction in code brings design into contact with the actual libraries and development patterns behind it, giving us a clearer view of what is possible.

More importantly, a working prototype gives both design and engineering teams the behavior itself to discuss. We can show how an interaction is meant to work, while engineering can respond to something it can inspect directly.

Even when the live product uses a different stack, the prototype remains a precise reference for the intended behavior. Where both share a coded design system and there is an established protocol between the teams, the handoff can go further.

Once approved, the prototype gives both teams a reference they can return to. That remains useful whether someone from the development team took part in the review or encountered the handoff afterwards. Everyone can return to the same approved behavior.

The result is a more complete package as a handoff, and in cases where the coded foundation is shared, engineering also has access to components it can build from.

The standard we now hold prototyping to

A prototype is also a statement about how precisely a design team is willing to define its intent. The more of the experience we give form to ourselves, the less we leave for a client or engineering team to piece together.

Prototypes may cover a single interaction or an entire flow. Whatever their scope, the people reviewing them should be able to experience them as being real and tangible. Building in code at design speed now makes that a reasonable standard to hold.

In part two of this series on ultra-high-fidelity prototyping, we will show the process behind this standard, including the groundwork that makes this fidelity possible and the studio’s role in shaping the prototype.