A polished screen is not the same as a resolved problem
Consider a hypothetical proposal tool with an elegant dashboard. Its new users still struggle to send their first proposal because the product asks them to configure a brand kit, team permissions, and billing details before they can try the core task. The visual quality is real. So is the extra work.
This is an illustrative teardown, not an assessment of a named product. The point is to separate aesthetic refinement from progress toward the user’s goal. The right next design decision depends on the task and the evidence, not on whether a screenshot looks finished.
Choose the smallest complete journey
For this example, define a narrow journey: create a draft proposal, check its details, and send a preview to yourself. Identify which setup steps are genuinely required for that task. Some may be necessary for security or accuracy. Others might be delayed until they become relevant.
Do not remove friction indiscriminately. A confirmation before sending a real contract can be useful. An unexplained request for unrelated information may not be. Record the purpose of each step before deciding to remove it.
Design the next useful step—not just the next beautiful screen.
Prototype the decision that matters
Build enough of the flow to let someone attempt the task. That might mean a few linked screens with plausible content and recovery states. It does not require an entire production product, but it does require the important choices to be represented honestly.
Include an empty state, an error, and a success state. Explain which parts of the prototype are simulated. Do not let a facilitator quietly complete difficult steps for a participant and then call the journey easy.
Listen for the cost of continuing
Ask the participant to attempt a realistic task. Observe what they notice, misunderstand, skip, and revisit. Afterward, ask what they expected and what they would do next. Record observations separately from your proposed solution.
Observation: participants look for a way to preview before providing billing information. Hypothesis: an optional preview path would help them judge relevance. Proposed test: make a preview available with a clear explanation of what remains required for sending a real proposal.
Make “better” specific enough to evaluate
Define the intended improvement before testing: successful completion of the task, fewer avoidable errors, a clearer understanding of the next step, or less unnecessary work. Pick the measure appropriate to your study and be transparent about sample and limitations.
A small usability study can identify problems worth investigating. It does not establish a reliable percentage lift in revenue. A production experiment has different requirements. Keep those forms of evidence separate.
Make one useful change, document what happened, and decide what to do next. Progress is not an excuse for careless work. It is a way to make the next piece of work accountable to a real customer need.
