Give the review a task, not just a screen.
A client looking at a polished screen might focus on the color of a button while you are trying to settle the order of a checkout flow. Before sharing, explain who the design is for, what they are trying to do, and which decision this round should make.
A sample review invitation
“Please review the appointment-booking flow for a returning customer on mobile. This round focuses on choosing a time and confirming the booking. The illustrations are placeholders. Start on screen 1 and follow the numbered screens to the confirmation.”
Show enough context to make the review meaningful. Include the preceding screen, the result of the main action, and relevant empty or error states. Label what is a static mockup, what is interactive, and what is still undecided. A screenshot cannot demonstrate keyboard behavior or prove that a flow works.
Find the exact moment that feels wrong.
Ask the client to locate the friction before offering solutions. You are looking for what they expected and what the design appeared to do instead.
“The page feels too busy.”
Try: “What were you trying to find when it felt busy?”
If the answer is the booking action, ask which content competed with it. That points toward a hierarchy problem to investigate, rather than a general instruction to remove useful information.
“Make the button bigger.”
Try: “Is the concern noticing the button, understanding what it does, or selecting it?”
Those are different problems. A size change may help one without addressing the others. Keep room for the client to describe another concern.
Other useful questions include “Which screen are you referring to?”, “What did you expect to happen next?” and “Does that concern apply to mobile, desktop, or both?” Ask only what the previous answer leaves unclear.
Separate stakeholder preference from usability evidence.
A client’s reaction can reveal business priorities, missing information, or an unclear presentation. It does not automatically describe how target users behave. Record the source of a concern alongside the concern itself.
“Our support team regularly gets this question” gives you something to investigate. “Nobody will understand this” is a hypothesis. Ask what prompted it and whether there is an example or existing observation you can review.
Keep visual preferences, business requirements, and usability questions distinct. Where a claim concerns whether people can complete a task, identify how you will evaluate it with the appropriate users or checks. A stakeholder’s approval of a mockup is not a substitute for usability or accessibility evaluation.
Keep earlier answers attached to the flow.
One comment can contain several concerns: “The first screen is crowded, and I don’t know if my booking went through.” Capture these separately, with the screen or state each belongs to.
For each thread, note the user’s task, the client’s concern, the intended outcome, and anything to preserve. If the client later clarifies the confirmation screen, do not treat that as a resolution of the crowded first screen.
Siftback can help clarify reactions to supported uploaded PDFs and images, using earlier answers to inform follow-ups and organizing the resulting feedback into suggested tasks. For an interface review, provide an annotated screen sequence and relevant brief. This is a review of the supplied work, not a live website inspection or interactive prototype test.
Turn two reactions into a focused revision brief.
Fictional example for an appointment-booking interface. These are illustrative questions, not guaranteed AI responses.
The original feedback
“It’s a bit confusing. The first page is busy, and the ending feels unfinished.”
The clarification
- Designer
- What were you trying to find on the first page?
- Client
- The available times. The service description takes up most of the mobile screen.
- Designer
- Does the full description need to stay visible while someone chooses a time?
- Client
- No, but they should still be able to read it before confirming.
- Designer
- What feels missing at the end?
- Client
- I can see the date, but I don’t know whether the appointment is booked or just selected.
- Designer
- So we need clearer access to times, plus a clear booking status on the last screen?
- Client
- Yes. Keep the date and location visible there too.
The brief for revisions
Confirmed: Make available times easier to find on the mobile selection screen while keeping the service details accessible. Make the final booking status explicit, retaining the date and location.
Designer’s next step: Explore a more compact service summary and clearer confirmation wording. Check the real booking states with the product team, then evaluate whether people can select a time and recognize a completed booking.
Finish with decisions and open questions.
Stop clarifying when you know the affected screen, the task, the problem, and the intended outcome. You do not need the client to choose every spacing value or interaction detail.
Separate agreed revisions from assumptions to test and dependencies to confirm. A request to add a new booking option may require a scope decision, not another visual iteration. Share a short recap before making changes, and state what the next review will assess.
For more on neutral questions and knowing when to stop, read the guide to useful logo feedback. The work differs, but the habit is the same: understand the reaction before choosing the fix.