Clarify the review question
1- Write the exact product decision the UX review must support.
- Name the target user, device, traffic source, and conversion moment.
- Remove visual comments that do not affect comprehension, trust, or completion.
Template for UX reviews
Run UX reviews that produce a fix queue, not a comment pile.
Use this checklist before shipping a landing page, onboarding path, pricing page, or product flow. It keeps the review focused on comprehension, task completion, trust, mobile friction, and measurable fixes.
6 passesQuestion, first screen, task path, trust, mobile, fix queue.
18 checksSpecific review items for product and acquisition surfaces.
30 minutesA practical review loop for teams without a research department.
Checklist
Review the path users actually take
The review is complete when every finding can be assigned to one fix owner and measured in the next release. Do not let the session drift into taste-only feedback.
Check first-screen comprehension
2- Confirm the user can identify the offer, value, and next action in five seconds.
- Make the primary CTA visually stronger than secondary exits.
- Check whether price, risk, or setup expectations are visible before commitment.
Review the task path
3- Walk through the happy path without using internal product knowledge.
- Mark every place where the user must choose, wait, compare, or recover.
- Check that empty, loading, error, and success states explain what happens next.
Audit trust and evidence
4- Separate proof from decoration: screenshots, examples, numbers, and source links matter most.
- Remove vague claims that are not supported by the current page.
- Place risk-reducing details near the decision, not in a footer paragraph.
Score mobile friction
5- Verify every button label fits and every tap target stays stable.
- Check that forms, pricing tables, and comparison rows do not force horizontal guessing.
- Make long labels wrap intentionally instead of shrinking with viewport width.
Write the fix queue
6- Separate must-fix blockers from polish comments.
- Assign each issue to copy, layout, component state, data, or tracking.
- Stop the review when the next build can be tested with one clear hypothesis.
Review output
Turn comments into a measurable fix queue
Every UX review should leave behind a short queue that engineering, design, and growth can execute without reinterpreting the feedback.
Blocker
The user cannot understand, trust, or complete the main path. Fix before traffic or launch.
Friction
The path works, but hesitation, rereading, weak copy, or mobile layout increases drop-off risk.
Instrument
The team needs event tracking, source labels, or funnel evidence before deciding the next change.
FAQ
Questions before your next review
What is the difference between a UX review and a design critique?
A UX review evaluates whether users understand and complete a task. A design critique can include taste and brand direction, but this checklist keeps the review tied to comprehension, trust, and conversion risk.
How often should a solo founder run a UX review?
Run one before shipping a new acquisition page, pricing change, onboarding step, or checkout flow. The review should be short enough to repeat after every meaningful product change.
What should be tracked after the review?
Track pageviews, CTA clicks, scroll depth, form starts, completion, and exits on the reviewed path. A UX review is only useful when it creates a measurable fix queue.