Start with the task, not the visual verdict
A redesign can look more polished while making an important task harder. Before comparing screens, describe who is trying to do what, where they begin, and what completion means. For an appointment flow, the task might be to find an available slot, understand the commitment and reserve it. A cleaner calendar is useful only if it supports that task. Write down the current problem and its evidence before you settle on an alternative. If you are practicing with a fictional interface, say so; the example can demonstrate reasoning without claiming a real customer problem.
Make one decision visible
Choose a comparison that reveals a consequential change: moving the total before the purchase action, preserving entered work after an error, or postponing optional setup until after the first useful task. Annotate what changed and the uncertainty it addresses. A screenshot caption such as “reduced cognitive load” is too broad without a clear mechanism. Try “the full order cost is visible before the final purchase action.” That describes something someone can inspect. Keep the original problem, proposed change and expected benefit separate so a viewer can challenge the reasoning.
Name the tradeoff before someone else has to
Removing a field may reduce effort, but that field could support delivery, qualification or fraud prevention. Discuss the dependency with the relevant team before removing it. Deferring invitations may help an individual start a project while delaying collaboration. Guest checkout may help an occasional buyer while changing account recovery and support needs. A useful review explains who benefits, what becomes harder, and which requirement needs confirmation. The goal is a defensible choice within constraints rather than a screen that appears universally better.
Write a testable question
Ask what you would need to observe to decide whether the alternative is useful. For transparent checkout, ask whether people can explain the final amount and whether the next action charges them. For error recovery, observe whether someone can locate the issue, correct it and keep the rest of their work. Use a neutral task that does not name the control you want them to choose. Record the task outcome, assistance, hesitation and relevant comments. Decide which observations would make you change the design before you start reviewing sessions.
Choose evidence that fits the claim
A small qualitative study can reveal confusion and recovery problems. It cannot, on its own, establish a population-wide conversion increase. If you want to estimate a conversion effect, you need a suitable measurement plan, reliable instrumentation, sufficient traffic and attention to other changes occurring at the same time. A before-and-after rate may change because the audience, offer, season or traffic source changed. Report counts and denominators, explain the comparison and keep uncertainty visible. Do not turn a plausible design benefit into a percentage you have not measured.
Keep a short decision record
Capture the task, the observed problem, the alternatives, the chosen change, the tradeoff and the next test. After evaluation, add what happened and what remains uncertain. The record helps a team avoid repeatedly debating the same screen without new evidence. It also makes a stronger portfolio story: readers can follow how you moved from a concern to a decision and then to learning. Try one Design Lab example, write your own alternative, and identify an observation that would cause you to choose differently.
Put this guide to work
Want help choosing what to change and what to test?
See the deliverables, boundaries, and next step before you book.
Explore the scope ↗Keep exploring
How to prioritize UX friction without giving your product a made-up score
What to bring to a UX review so you leave with useful decisions