A preview link is a chance to check how the product works for your users before the next release. The most useful feedback explains what you were trying to do, what happened and why it matters. You do not need to diagnose the code or design the fix.
I work through reviews in writing. A clear set of observations gives us a shared record of the decisions and helps me make the right change, then show you how it was checked.
Start with the purpose of this review
Read the preview notes first. They should explain what is ready to review, what is still being worked on and which decisions need your input. A layout review and a review of a completed checkout flow need different kinds of feedback.
Use the agreed scope as a reference. If something is missing from the preview, check whether it belongs to this milestone or a later one. When the notes are unclear, point out the uncertainty so we can resolve it before drawing conclusions.
Try a complete task as the intended user
Choose a realistic task and work through it from the beginning. For a booking product, find a service, choose a time, check the details and complete the test booking. Watch for information you need but cannot find, confusing choices and places where you lose your progress.
Then check the parts relevant to your role. Staff may need to find the booking and handle a cancellation. If you can involve representative users, give them a task and observe where they struggle without immediately explaining the interface. GOV.UK’s usability-testing guidance describes this approach in more detail.
Describe the observation and its impact
“Make this clearer” gives me a direction but leaves the problem uncertain. A more useful observation is: “On the booking summary, I cannot see which time zone applies. Our customers book from different countries, so they need to know that before paying.”
For a problem with behaviour, include the steps, what you expected and what happened. Note the device and browser when relevant. A screenshot or short recording can help show the location; remove private customer information before sharing it.
Page or preview link: …
Task I was trying to complete: …
Steps that led to the issue: …
Expected result: …
What happened or what was unclear: …
Who this affects and why it matters: …
Device/browser and a screenshot, if useful: …
Separate an observed problem from a proposed solution
Suggestions are welcome. Include the reason behind them so I can assess whether the change solves the underlying issue. “Add a red button” is a possible solution. “Staff keep missing the overdue orders” explains the need and gives us more ways to address it.
For visual feedback, point to the element and explain the goal: easier scanning, consistency with your brand, or making the next action more apparent. Preferences and user problems are both worth discussing; identifying which one you mean helps us make a decision.
Group feedback and make the decisions visible
Keep related observations together in one written thread or agreed review location. If several people are reviewing, name the person who can resolve conflicting requests and confirm the final direction. That avoids implementing one person’s suggestion only to discover another person had a different requirement.
Issues that block an agreed task or release.
Improvements to the behaviour or presentation being reviewed.
New ideas to assess for a later iteration.
A new requirement can affect the scope and timeline. We should discuss that impact and agree on the next step before adding it to the current work. Keeping a later-ideas list lets you capture useful suggestions without losing sight of the release being reviewed.
Confirm the result after the change
When I provide an updated preview, repeat the task that exposed the issue. Check that the result meets the agreed outcome and tell me if anything remains unclear. If a follow-up reveals a different problem, record it separately so we can track both clearly.
An approval should identify the preview or milestone you reviewed and any accepted limitations or remaining work. For example: “I checked the booking flow on the agreed phone and desktop views. The time zone is now visible before payment. The calendar export remains in the next milestone.”
This keeps the review useful to everyone: you can see how your feedback changed the product, and I have a clear record of what is agreed. If you are starting a project, the same habit begins with a brief that describes the outcome you need.