A prototype can show how a product works. Presenting it introduces another problem: how does someone know what is worth exploring?
While building Relay, a referral experience for property agents, I found that a single walkthrough could only show part of the work.
The interesting questions were spread across different contexts. What does a new agent see? What changes when a referral needs attention? How does the experience communicate an unreachable client? What happens to the same layout in Arabic?
I built a viewer around the prototype to make those situations easier to inspect.
A walkthrough has a point of view
A linear demonstration is useful. It gives a presentation a clear beginning and end.
It also means the presenter decides which states the reviewer sees. An exception can remain hidden behind several interactions, even when that exception contains an important design decision.
Relay included 15 scenarios. Asking someone to discover each through the product would have made the review depend on navigation and setup as much as on the design itself.
I wanted the presentation to give reviewers a direct way into different situations.
Scenarios as entry points
The viewer lets a reviewer explore selected contexts without manually recreating every preceding step.
That changes what the prototype is useful for. It can support a focused conversation about one state as well as a broader product walkthrough.
An unreachable-client scenario, for example, gives us something specific to inspect: what the agent understands, who is responsible and whether the next action makes sense.
The scenario is a demonstration fixture. It is not evidence that the operational workflow has been validated.
Showing the reasoning alongside the interface
A finished screen rarely explains the decisions behind it.
Optional design notes let me put that reasoning near the relevant experience. They give a reviewer more context while allowing the interface to be explored on its own.
I wanted the notes to explain choices and trade-offs, rather than repeat what a screen already said.
There is a useful distinction between an interface instruction and a design explanation. The product should help an agent complete a task. The viewer can explain to a reviewer why I chose a particular pattern.
Those two audiences need different information.
Language changes the review
The viewer includes English and Arabic layouts.
Being able to inspect the RTL variant made direction, alignment and mixed-language content visible parts of the conversation. It also kept the English layout from becoming the only version represented in a walkthrough.
The presence of a language toggle does not establish that localisation is complete. Arabic copy and substantive flows still need review with Arabic-speaking users.
Code as a design environment
The prototype uses React 19, TypeScript, Tailwind 4 and Vite.
I directed Claude Code to help build reusable foundations and components before developing the screens and scenarios. Working with an interactive implementation let me inspect relationships between states, copy and actions.
One useful example was an unreachable-client case whose timeline implied that contact had already happened. Fixing that contradiction required changing the meaning of the state, then bringing the corresponding Figma screen into alignment.
I describe the wider workflow in Building a shared language between design and code.
The viewer also includes a reference for the underlying design system. That gives reviewers another way to inspect how the pieces connect.
What the viewer does not prove
Making a prototype easier to inspect is different from making a product ready to ship.
Relay contains illustrative client data, amounts and business rules. Some handoffs and account actions are simulated or placeholders. Payment and reward fulfilment are outside its scope.
The viewer makes those design situations accessible for discussion. It does not validate referral consent, operational reliability, commercial rules or adoption.
I also have not measured whether reviewers understand the work better because of the viewer. That remains something I would want to test.
What I would do differently next time
I would test the review experience earlier.
Can someone find a relevant scenario without guidance? Can they tell which controls belong to the viewer and which belong to the product? Do the notes help them understand a decision, or interrupt their reading?
I would also document each scenario’s purpose, fixture data, expected state and limitations. That would make it easier to maintain the presentation as the product changes.
Keyboard navigation, focus behaviour, reduced motion and narrow-screen layouts should be reviewed across the viewer as well as the embedded experience.
The value of making work explorable
Building the viewer made me think about presentation as part of design practice.
A portfolio visitor may want a quick overview. A designer may want to inspect an exception. An engineer may want to understand the component system.
The viewer gives those conversations a shared place to start.
The broader product story is in Relay: Bringing clarity to property referrals.
