What to bring to a UX review so you leave with useful decisions

Choose one decision the review should support

“Review our whole product” leaves the reviewer guessing about scope and importance. Choose one journey and explain the decision you need to make. You might be preparing to test an onboarding flow, investigating a difficult checkout step, or deciding which prototype issues to address before development. State who uses the journey, what they are trying to accomplish and why this decision matters now. You do not need a polished presentation. A concrete task and a candid account of the uncertainty make a better starting point.

Share the actual flow, including the awkward states

Provide the relevant screens or a prototype, with enough context to understand where someone starts and finishes. Include loading, error, empty, permission and success states if they exist. If they are missing, identify the gap rather than designing them hurriedly to make the package look complete. For a bounded review of up to five screens, confirm which screens count and whether additional states fit the agreed scope. Explain simulated behavior so no one mistakes a prototype confirmation for a working payment, appointment or data save.

Bring evidence with its source and limitations

Useful inputs can include anonymized support themes, task observations, funnel counts, customer questions or prior research findings. Attach the source, date and relevant context. Distinguish direct observations from stakeholder interpretation and assumptions. If you do not have research or analytics, say so. An expert review can still identify plausible concerns and missing specifications, but it cannot claim findings from users who were never observed. Protect personal and confidential information; share only what you are permitted to disclose and confirm the access method before sending materials.

Make constraints visible

Tell the reviewer what cannot change easily: platform limitations, regulatory requirements, delivery dependencies, release timing, content ownership and engineering capacity. Identify decisions that have already been made and whether they can be revisited. A recommendation that ignores a real constraint is difficult to act on. At the same time, distinguish a confirmed requirement from a habit or an assumption. “Engineering needs an account before billing” is something to verify; “we have always asked for registration first” does not, by itself, establish a dependency.

Know what the review gives you

The UX Decision Review on this site covers one journey, up to five screens, annotated findings, three prioritized improvements, a 60-minute working review, a practical test plan and one clarification round. Scope is agreed before paid work begins. It is a focused expert review, rather than a full redesign, participant research study, production implementation or accessibility certification. The illustrative sample shows how an observation becomes a concern, recommendation and next check. Ask for clarification if your needs extend beyond the published deliverables.

Use the meeting to make the next move concrete

During the review, ask which recommendation depends on an unverified assumption, which issue blocks the task and what should be tested before implementation. Close with a short record of the decision, owner and next action. If the right answer is to gather evidence, give that work a scope and date instead of treating it as a vague research phase. The free fit call checks whether the engagement matches your needs; it does not purchase or reserve the paid service. Before paying, confirm deliverables, timing, price and the applicable rescheduling, cancellation and refund terms.

Put this guide to work

Bring one journey. Get a clearer next decision.

See the deliverables, boundaries, and next step before you book.

Explore the scope ↗

Keep exploring

A better-looking redesign is a hypothesis. Here is how to test it.

How to prioritize UX friction without giving your product a made-up score