How we review designs with clients: one prototype, one phone, one decision

Design reviews used to be the slowest part of our projects. Not the designing, not the building: the week of waiting between "here's the new version" and a clear answer. Feedback arrived in email threads, chat messages and screenshots with red circles, often about an older version than the one we'd just sent.

So we built our review process around one idea: the client should review the design the way their customers will use it, on a phone, in their hand, and their feedback should land exactly where it applies. This is how that works today, and what we've changed along the way.

The setup

Every design we review is a running prototype, not a set of frames. We build it in the same stack as the product, usually React Native with Expo, and export a web build of just the flow under review. That build is published as a new version into the Ainur Design app.

On the client's phone, the app opens the version full-screen inside a native shell. It uses the platform's WebView, with the bundle served from local files through Android's WebViewAssetLoader rather than from an open website. There's no browser bar and no reviewer toolbar in the way. The system bars, the back gesture and the safe areas behave as they would in the shipped app, so the CEO is judging the design, not our tooling.

• One link per design. The client signs in once with an account we invite them to. New versions appear in the same place, marked as new.
• Versions are immutable. Version 4 is always version 4. Comments and decisions stay attached to the exact build they were about.
• A changelog per version, in plain words: "Moved the filter into the search bar. Added the empty state. Fixed the card title wrapping."
• Test tasks, a short checklist of what to try: "Find a class on Thursday evening and book it." "Cancel the booking." The reviewer ticks them off as they go.

Feedback that lands on the screen

The most useful change was moving feedback into the prototype itself. While using it, the reviewer can stop on any screen and leave a comment. The comment is tied to the version and the screen it was made on, with an optional pin on the exact spot, a screenshot, or a voice note.

Voice notes turned out to matter more than we expected. Busy executives review on the move, between meetings, sometimes walking. Typing a careful paragraph on a phone is a chore. Saying "this button feels too far down, I have to stretch for it" takes four seconds, and we hear the tone too: whether it's a passing thought or a real problem.

Comments are threaded, so a designer can reply on the same pin ("Moved it up in v5, can you check?") and mark it resolved. The client sees which of their points were acted on and in which version.

One decision per version

Each reviewer gives each version one of two answers: approve or request changes. That's it. No "looks good overall but", no silent approval by not replying.

This is deliberately blunt. In the old process a design could be half-approved for weeks: the CEO liked it, someone else had a concern, nobody said no. A per-version decision forces the question at the right moment and leaves a record. When a later version changes something, the earlier approval doesn't silently carry over to it.

What the analytics add

The app records a small set of events per version: the prototype was opened, which screens were viewed and for how long, and which test tasks were ticked. We read these next to the comments, never instead of them.

They answer a question comments can't: what did the reviewer actually try? Sometimes a design gets approved and the analytics show the reviewer never reached the screen we were most worried about. That isn't a failure on their side. It tells us to add a test task, or to walk them through that part in our next call. Other times a screen gets far more time than its content justifies, which usually means someone was lost, even if the comment says "fine".

We're careful with this. It's a review tool, not surveillance, and clients know what we record. The goal is a better conversation, not a score.

The shape of a review week

Not every week looks like this. Early on, when we're still choosing a direction, we review static explorations instead. And a small fix can go out mid-week as its own version. But this rhythm is the default, and having a default helps everyone plan.

What we've learned

• Small rounds beat big reveals. Nielsen Norman Group has argued for years that several small tests find more than one large one. The same is true of client reviews. A focused version every week gets better feedback than a big version every month.
• Test tasks focus the review. Without them, reviewers tour the home screen and comment on colours. With three concrete tasks, they reach the parts of the flow where the real decisions are.
• Real content changes the conversation. Prototypes with realistic data (long names, empty lists, slow loading) get comments about the product. Prototypes with perfect placeholder data get comments about the visuals.
• Changelogs build trust. When every version says what changed and why, clients stop re-checking everything and start checking what's new.
• Say what's fake. A prototype that feels real can be mistaken for an almost-finished product. We state in the changelog what is stubbed: payments, notifications, anything outside the flow.
• People comment differently than they act. Comments tell us what reviewers think. Screen analytics and ticked tasks tell us what they did. The useful insight is usually in the gap, which is the same reason usability researchers watch people think aloud rather than just asking them afterwards.

What it changed for us

The most visible effect is fewer surprises late in a project. Problems with reach, scrolling, empty states and wording come up in the review where they're cheap to fix, not in the first week after launch. Decisions are clearer because each one is attached to a version, and nobody has to search an inbox to find out what was agreed.

The less visible effect is on the relationship. A CEO who has held every version of their product in their own hand, and seen each of their comments answered on the screen where they made it, trusts the process. That trust is worth more than any single design.

• Review running prototypes on the client's own phone, not in a meeting room
• Make every version immutable, with a plain-language changelog
• Give three to five test tasks per version
• Collect feedback on the screen it's about, and allow voice notes
• Ask for one decision per version: approve or request changes
• Read what reviewers did next to what they said

Sources

1. Build web apps in WebView · Android Developers
2. WebViewAssetLoader · Android Developers
3. Publish websites · Expo Documentation
4. Why You Only Need to Test with 5 Users · Nielsen Norman Group
5. Thinking Aloud: The #1 Usability Tool · Nielsen Norman Group