Questions to Ask When Conducting a UX Review
For a UX designer or researcher auditing a product by expert review, the kind of heuristic evaluation done with no users in the room. These are the questions to ask yourself of each screen and flow, in the order a review runs: setting the scope, finding the next step, feedback and errors, consistency and content, accessibility, then rating and reporting.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Scope
Who is this product for, and what did they come here to do?
Why ask it
Write down two or three kinds of user and the main task for each before you open the product. If you cannot, the review has nothing to measure against, so ask the product owner or read the support queue first. A review done as 'a general user' mostly finds what annoys the reviewer.
Why was this review asked for, and what will be done with the findings?
Why ask it
A review ahead of a redesign, one prompted by a fall in sign-ups and one a new manager wants as a baseline each call for depth in different places. Ask what is already decided and what cannot change, such as a payment provider's hosted page, so you do not spend a day on screens nobody can touch. If no one can say what happens after the report, settle that before you start.
Which tasks will I walk through, and where does each one start and end?
Why ask it
Choose a handful of tasks that matter to both the user and the business, and give each a realistic starting point, such as a search result or an email link, not always the home page. Write down what is out of scope too, and get a nod from whoever asked for the review. A task list that covers the whole product means the last flows get a tired reviewer.
Which set of heuristics or principles am I judging against?
Why ask it
Nielsen's ten usability heuristics are the usual choice, and some teams add their own design principles or a checklist for their kind of product. Naming the yardstick up front is what separates a finding from an opinion. If a real problem fits no heuristic, keep it anyway and explain how it hurts the task.
Which device, screen size and setting will they really be using?
Why ask it
Review on the device where most of the use happens, and if nobody can tell you which that is, ask for the analytics before you begin. A flow that is comfortable on a wide monitor at a desk can fall apart one-handed on a phone. Record what you tested on so the report can say so.
What does this person already know when they arrive, and what do they not know?
Why ask it
A first-time visitor and a daily user need opposite things from the same screen. Pin down their vocabulary, their knowledge of the subject and how often they come back. The worrying discovery, halfway through, is that you have been judging an expert's tool by a beginner's standards.
What evidence already exists: support tickets, analytics, findings from earlier tests?
Why ask it
An expert review predicts problems, and this material shows which ones are already happening. Decide whether you read it before your pass or after, and say which in the report, because it changes what you notice. If your findings and the tickets point in different directions, that is a case for a usability test and not for trusting either one.
Next step
On landing here, can I tell where I am and what this screen is for?
Why ask it
Look away, look back, and say in one sentence what the page is for. The title, the heading and the highlighted item in the navigation should answer between them. If you had to read the body text to work it out, so will everyone who lands here from a search result or a shared link.
Is the next step obvious, and is there one clear primary action?
Why ask it
Squint at the screen: the thing that stands out should be the thing most people came to do. This is the visual hierarchy check, and it usually fails in one of two ways: two equally loud buttons, or a primary action below the first screenful on the common device. Name what competes with it, because the fix is often to quiet something else.
Does everything that can be clicked look clickable, and nothing else?
Why ask it
Hunt for plain text that turns out to be a link, and for colored or underlined text that does nothing. A touch screen has no hover state to settle the doubt. Each wrong guess teaches a user to trust the interface a little less, so these matter more than their size suggests.
Do the navigation labels use the words this user would use?
Why ask it
Internal product names, department names and clever labels are the usual offenders, and the people who coined them can no longer see the problem. Before opening each menu item, guess what sits behind it. Where the guess was wrong, note what you expected and what you found: that pair persuades a team better than 'the label is unclear'.
If I search for something, do I find it, and what happens when nothing matches?
Why ask it
Try the user's own word, a misspelling, a plural and a product code if there is one. Useful results for the first and a dead end for the rest is a common pattern. On the no-results screen, look for a suggested spelling, a broader category or a way to ask a person. Where the product has no search at all, ask whether one this size should.
How many steps does this task take, and which of them give the user nothing?
Why ask it
Count the screens, fields and decisions in each scoped task. The total means little on its own. What you are looking for is the step that serves only the company, such as creating an account before the user has seen anything of value. For each one, write what the business would lose by dropping or delaying it, because that is the argument the team will have.
Can I go back, cancel or undo without losing my work?
Why ask it
Use the browser's back button, the close icon and a page refresh in the middle of each flow. The flow should keep what was entered, or warn before throwing it away. A half-finished form lost to one stray tap rates high on severity even if it happens rarely.
What does the screen ask me to remember from an earlier step?
Why ask it
Catch yourself scrolling back, opening a second tab or writing something down: a code shown once, the name of a plan, a price. Each is something the screen could have carried for you. The answer you want is 'nothing'. For anything else the recommendation writes itself: say where the information should reappear.
What does a new user see the first time, before there is any data?
Why ask it
You need a brand-new account to see this, which is why it gets missed: the team's own accounts are full. An empty state should say what will appear here and offer the action that fills it. A bare table of column headings, or a dashboard of zeros, gives a newcomer no reason to carry on.
Is there a faster route for someone who does this every day?
Why ask it
Keyboard shortcuts, remembered defaults, bulk actions and recent items matter a great deal in a tool used daily and hardly at all on a form filled in once a year, so skip this for the second kind. For the first, the worrying answer is that the hundredth use takes exactly as long as the first.
Feedback and errors
After every action, does the system show that something happened?
Why ask it
Press each button and watch for a change straight away: a new state, a spinner, a message. Where nothing appears to happen, people press again, and that is how duplicate orders and double-sent messages come about. Save, send and pay are the three to check first.
During a wait, do I know it is still working and roughly how long it will take?
Why ask it
A fast office connection hides this one, so slow the network down in the browser's developer tools if you can. What you hope to see is progress shown and a layout that holds still. Content that jumps as it loads moves a button out from under a thumb, so state in the report what speed you tested at.
When something succeeds, is it clear what was done and what comes next?
Why ask it
Plenty of confirmation screens say 'Thank you' and stop. Check that the screen restates what was done, says what happens next and when, and gives the user somewhere to go. After a payment or a booking, look for a record the person can keep.
What can go wrong at this step, and does the design prevent it?
Why ask it
List the likely slips: a date in the wrong format, a mistyped email, a destructive button sitting beside a harmless one. Prevention is worth more than a well-written error message, so look for constraints, sensible defaults and a confirmation before anything that cannot be undone. Where the design leaves a slip open, recommend the constraint, not a kinder apology.
Does each error message say what went wrong, in plain words, and how to fix it?
Why ask it
Set off every error you can: empty fields, wrong formats, an expired session. The message should sit next to the problem, name it without codes or blame, and say what to do. Copy the exact wording of each weak one, such as 'Invalid input', into your notes so a writer can replace the lot in one sitting.
After an error, is what I entered still there?
Why ask it
Fill in a long form with one field wrong, submit it, and see what survives. A form that clears everything turns one mistake into a second attempt that some people will not make. Password and card fields are often emptied on purpose, so name which other fields were wiped and leave those two to the team's judgment.
Do forms tell me the rules before I break them?
Why ask it
Password requirements, character limits and required fields belong on the screen before submission, not revealed one at a time afterward. The opposite fault counts too: validation that fires on the first keystroke and scolds a half-typed email address.
If I get stuck, is there help within reach of the place I am stuck?
Why ask it
Look for hints beside the field, a help link that opens on the relevant topic, and some way to reach a person. A help center that opens on its own front page makes the user describe the problem from scratch. On a simple consumer flow the best result is that you never needed any.
What happens at the edges: a very long name, no connection, a session that timed out?
Why ask it
Paste in a long name, one with an apostrophe or an accent, and an address that does not fit the expected pattern, then drop the connection in the middle of a task. These cases are rare for any one person and routine across a whole user base. They are also where layouts break and entered data disappears.
Consistency and content
Does the same word mean the same thing on every screen?
Why ask it
Keep a running list of terms as you go. 'Cart' on one page and 'basket' on another, 'delete' and 'remove', 'project' and 'workspace': users assume a different word means a different thing. The finished list makes a useful appendix, and the content team can act on it directly.
Do the same components look and behave the same way throughout?
Why ask it
Compare buttons, form fields, dialogs and tables across the flows you scoped. A primary button in two colors, or a date picker that works two different ways, often marks the border between two teams' work. A pair of screenshots side by side makes the point faster than a paragraph.
Does this follow the conventions of the platform and of similar products?
Why ask it
People spend most of their time in other products and bring those habits with them. Note where the design departs from the operating system's patterns or from what the category does, such as a logo that does not lead home. A departure is not wrong in itself, so ask what the user gets in exchange.
Does the product do the same things, under the same names, on a phone as on a desktop?
Why ask it
Run one scoped task on each and compare. Features that vanish on the small screen, a menu whose labels change, and an email link that opens a page the app cannot show are the usual breaks. Someone who starts a task on one device and finishes on another meets both versions, so a gap here can strand them halfway. Skip it if only one platform is in scope.
Would a newcomer guess what each icon means?
Why ask it
Cover the labels and name each icon's function out loud. Any you hesitate over needs a text label. Pass over the few nearly everyone knows, such as the magnifying glass for search, and spend the time on icons invented for this product.
Can I understand each sentence on the first read?
Why ask it
Read the interface text aloud. You will stumble on the jargon, on double negatives such as 'Uncheck to not receive updates', and on sentences doing two jobs at once. Put a suggested rewrite beside each one, since a writer can improve a draft faster than work from a complaint.
Do headings and button labels say what will happen?
Why ask it
Someone scanning reads only the headings and buttons, so do the same. 'Submit', 'Continue' and 'Click here' promise nothing, while 'Send message' or 'Pay now' set an expectation. The ones to worry about are buttons whose result you could not have predicted, above all where the result is a charge or a deletion.
Is anything the user needs for a decision missing, buried or shown too late?
Why ask it
Total price, delivery time, what happens to their data, how to cancel: each should appear before the commitment and not after it. A cost that first shows up on the final step is a trust problem as well as a usability one, and deserves a higher rating than its fix would suggest.
Does anything steer the user into a choice they did not mean to make?
Why ask it
Look for boxes ticked in advance, a decline link worded to shame, a cancel route far longer than the sign-up, and a countdown that starts again on reload. These may well be deliberate, so describe plainly what the user is led to do and what it costs them. How such patterns are treated differs from place to place, so flag them and leave that reading to the team's own advisers.
Is there anything on this screen that nobody would miss?
Why ask it
Ask of each block of text and each widget which task it serves. Welcome paragraphs, instructions repeated from the previous step and decorative carousels all compete with the thing the user came for. A removal is often the easiest recommendation for a team to accept, because it costs little to build.
Accessibility
Can I complete every task with the keyboard alone?
Why ask it
Put the mouse aside and tab through each flow. Focus should always be visible, move in a sensible order, reach every control, and never get trapped inside a dialog. It takes a few minutes, and what it turns up usually affects screen reader users as well.
Is the text readable: size, contrast and line length?
Why ask it
Run the body text, placeholder text and any text over images through a contrast checker, against whichever standard the team works to; WCAG is the common reference. Pale gray placeholders and captions are the usual failures. Then check two things a checker cannot: the screen on a phone outdoors, and paragraphs that stretch the full width of a wide monitor.
Is any information carried by color alone?
Why ask it
Switch the screen to grayscale and look again at error states, status badges, chart lines and the markers for required fields. Whatever you can no longer tell apart needs an icon, a label or a pattern as well. Red and green used as a pair for good and bad is the first place to look.
Do images, icons and form fields have text a screen reader can announce?
Why ask it
Turn on the screen reader built into your device and listen to one flow from start to finish. Controls announced only as 'button', and fields labeled by nothing but placeholder text, show up at once. If you are not practiced with a screen reader, say so in the report and recommend a specialist audit instead of vouching for the result.
Are touch targets big enough and far enough apart?
Why ask it
Go through the flow on a real phone with your thumb, not with a cursor in a narrowed browser window. Small close icons, links packed into a footer and a delete control beside an edit control are where the mis-taps happen. Record the ones where a wrong tap costs the user something.
Does the page still work when the text is enlarged or the browser is zoomed in?
Why ask it
Zoom the browser to double its default and raise the text size in the phone's settings. Watch for text that is cut off, overlaps its neighbor or forces sideways scrolling, and for buttons pushed off the screen. Plenty of people who would never describe themselves as disabled use these settings, so treat it as an everyday case.
Does anything move, flash or time out without a way to stop it?
Why ask it
Auto-advancing carousels, looping video, animated banners and a session that expires in the middle of a form all belong here. Each should offer a pause, respect the device's reduced-motion setting, or warn the user and let them ask for more time. For someone who needs longer with a screen, a slide that changes every few seconds is content they never get to finish.
Which accessibility standard is this product expected to meet, and who checks it?
Why ask it
The answer depends on the country, the sector and sometimes the contract, so ask the team or its legal contact how it works there instead of assuming. An expert review can flag likely failures, but it is not a conformance audit. The report should say plainly which of the two it is.
Rating and reporting
How severe is this problem: how many people meet it, how badly, and how often?
Why ask it
Judge each finding on those three things, then give it one level on a short scale such as cosmetic, minor, major or blocker. One problem that stops a main task for everybody outranks ten irritations. Add a line of reasoning so that the rating can be argued with.
Is this a usability problem, or my own taste?
Why ask it
Finish the sentence 'a user trying to do X would struggle here because' for each finding. If you cannot, and no heuristic applies either, it is a preference. Put preferences in a separate, clearly marked list or leave them out altogether.
Could someone who was not here find this problem from my notes?
Why ask it
Every entry needs a location (the screen, its state, the step in the task), a screenshot, the principle it breaks and the consequence for the user. If a developer cannot reproduce it from the entry alone, it will be waved away in the readout. Rewrite it while the screen is still open in front of you.
What is working well that should be protected?
Why ask it
List the strengths with the same care as the problems. It stops a redesign from removing them by accident, and a team that sees its good decisions recognized tends to read the rest more openly. If you have found none, go back and look, because few products have nothing worth keeping.
Would a second reviewer have found the same things?
Why ask it
One evaluator misses problems that another catches, which is why the method is normally run by several people working separately and merging their lists afterward. If you worked alone, say so and call the report a first pass. Where two reviewers disagree on a rating, record both and talk it through.
Which findings am I unsure of and should test with real users?
Why ask it
An expert review produces predictions, and some of them will be wrong, especially where you are nothing like the person the product is for. Mark the doubtful ones and turn each into a task for a usability test. A report that sounds certain about everything is harder to believe.
What do I recommend for each problem, and how confident am I in the fix?
Why ask it
Give a direction instead of a finished design: 'show the total before the payment step', not a mockup nobody asked for. Where several fixes would work, name the cheapest one that solves the problem, and say so when you are guessing. The detailed design belongs to whoever owns the product, unless that is you.
If the team fixes only three things, which three?
Why ask it
A list of sixty findings gets filed, and a short ranked one gets worked on. Choose by severity and by effort, and ask an engineer for a rough idea of cost if you can. Those three go on the first page.
Who will read this, and what does each of them need from it?
Why ask it
A director wants the main findings and what they cost the business. Designers and engineers want the full log with locations. Write a one-page summary and a detailed table instead of one long document for both, and ask the person who commissioned the review which format they will really open.
How to run an expert UX review
Practical guidance for the conversation itself
Before you open the product
Fix the users and tasks first
Answer the Scope questions on paper before you look at a single screen. A review with named users and four or five written tasks produces findings tied to something. A review without them produces a list of things the reviewer happened to notice.
Choose the yardstick and the scale
Settle which heuristics you are using and what each severity level means, in a sentence apiece, before the first finding. Deciding what 'major' means after you have a list invites rating by mood. If several people are reviewing, everyone uses the same definitions.
Set up the findings log
A spreadsheet is enough: one row per finding, with columns for the task and step, the screen and its state, a screenshot, the heuristic, the severity, the consequence for the user and a suggested direction. Filling the row in at the moment you see the problem is far easier than reconstructing it later.
Get realistic access
Ask for a test account that looks like a real one, with data in it, and for a fresh account with none. Many problems live only in one of the two. If payments or messages are involved, find out what is safe to trigger.
During the review
Go through each task twice
On the first pass, do the task straight through as the user would, to feel where it slows or stalls; that is where the Next step questions earn their place. On the second, stop on each screen and work down Feedback and errors, Consistency and content, and Accessibility.
Break things on purpose
The happy path is usually the best-designed part of any product. Leave fields empty, enter the wrong thing, go back mid-flow, let a session expire. The error and edge cases are where an expert review finds what a quick demo never shows.
Work alone, then compare
If there is more than one reviewer, each goes through separately and the lists are merged afterward. Reviewing together feels efficient, but the second person ends up seeing the product through the first person's remarks, and the overlap between two independent lists is itself useful evidence.
Keep sessions short
Attention to detail fades, and the flows reviewed last get less of it. Stop when you notice yourself skimming, and vary which task you begin with from one session to the next.
Rating and reporting
Lead with the few that matter
Open the report with the three to five findings that most damage the main tasks, each with a screenshot and one sentence on the consequence. The full log follows as a table. Assume that some readers will go no further than the first page, and make that page the one worth acting on.
Show the problem
An annotated screenshot or a short screen recording settles arguments that a written description starts. Mark the exact element, and where a comparison helps, put the inconsistent pair side by side.
Say what the method cannot tell you
State who reviewed, on what devices, against which heuristics, and that no users took part. An expert review predicts where people will struggle; it does not show how many do or why. Naming that limit makes the rest of the report easier to trust.
Present it in person if you can
Walk the team through the top findings live, in the product, before sending the document. People accept a problem they have just watched happen more readily than one they read about, and you hear at once which exceptions were deliberate.
Mistakes to avoid
Treating it as a replacement for testing
An expert review is quick and needs no recruiting, which is its appeal, but it reflects what a trained eye expects users to do. Use it to clear out the obvious problems before a usability test, so the test sessions are spent on the things only real users can reveal.
Reviewing screens instead of tasks
Going page by page through a site map finds visual and wording issues and misses the problems that sit between screens: lost data, missing confirmation, a step in the wrong order. Always review along a task.
Logging taste as findings
Once a team spots one entry that amounts to 'I would have done it differently', it starts discounting the others. Every finding should name a user, a task and a consequence. What cannot be written that way is a note for a design critique.
Handing over a list with no order
Eighty findings sorted by the page they appear on give a team no place to begin. Sort by severity, group repeats of the same underlying cause into one entry, and say which fixes you would make first.