Give the review a purpose before showing the work
A design concept can be easy to misread when its creator is not in the room to explain it. Before sharing screens or mockups, write a short introduction that reminds the client what the project is trying to accomplish, who the design is for, and which decisions are open for review. Keep this tied to the agreed brief rather than introducing new goals at the presentation stage.
Name the kind of feedback you need. An early concept review might be about direction, hierarchy, and tone, not button spacing or final copy. If something is included only to demonstrate layout, label it as placeholder content. Likewise, identify elements that are already agreed upon so the client does not spend time revisiting them. This framing helps both sides focus on decisions the review can actually move forward.
Build a presentation that stands on its own
Arrange the material in the order a client should read it: project goal, design principles, each concept, and then the questions to answer. Give every concept a short, descriptive name. For each one, explain the idea it explores, how it serves the goal, and any trade-off worth considering. A concept should not need a live sales pitch to make sense, but its explanation should not attempt to justify every visual choice.
Show each option at a comparable level of detail. If one direction has polished mockups while another has only rough sketches, the difference in finish may distract from the ideas being evaluated. Include enough realistic context to make the design understandable: a page in its likely setting, a few representative states, or examples at relevant sizes. If important interactions cannot be shown in a static image, describe what happens and what remains undecided.
Make the files easy to navigate. Use consistent labels across the overview and individual screens, and keep explanatory notes close to the work they describe. Check that text is legible without excessive zooming. A concise summary of the concepts is useful for someone returning to the review after a break, but it should complement the examples rather than replace them.
Ask for decisions, not general reactions
“What do you think?” can invite useful conversation, but on its own it rarely tells a client what kind of response will help. Ask a small set of questions connected to the review’s purpose. For example: Which direction best supports the intended audience? Where does the content feel hardest to understand? Is there anything that conflicts with a requirement we have already agreed on? Questions like these leave room for concerns while encouraging specific answers.
Separate preferences from requirements. A client may dislike a color, notice a missing feature, or worry that the overall tone feels wrong; those comments call for different responses. Invite them to explain the reason behind a requested change, especially when it relates to their audience or business constraints. This gives you a better basis for revising the design than a list of isolated edits.
If several stakeholders are involved, ask the client to identify who will approve the direction and how conflicting comments should be resolved. You can welcome comments from everyone without assuming that every suggestion can be applied. Establishing that distinction before feedback arrives makes the review easier to manage.
Make responding straightforward
Send one clear message with the review link or files, a brief statement of the decision needed, instructions for leaving comments, and an agreed response date. If there are multiple places to comment, specify which one will serve as the record. Let the client know whether you want feedback on individual screens, an overall direction, or both.
Give people a way to respond even if none of the concepts feels right. Ask them to identify what is missing or misaligned rather than forcing a choice between options. It can also help to distinguish questions you can answer immediately from feedback you will address in the next revision. Asynchronous does not have to mean silent: if a concern cannot be resolved clearly in writing, a short conversation may be more efficient than a long comment thread.
Close the loop with a decision record
After the review, collect comments in one place and group them by theme. Look for repeated concerns, conflicting requests, and points that need clarification. Then send a short recap: the direction chosen, the changes you plan to make, any questions still open, and what the client will see next. If a suggestion does not fit the agreed goal, explain the reasoning respectfully rather than ignoring it.
The value of an asynchronous review is not simply that people can respond at different times. It is that the work, the feedback, and the decision can remain understandable afterward. A clear recap gives the next design pass a shared starting point and helps prevent the same discussion from reopening with every revision.
