8 Improving Designs Through Evaluation
Learn how to turn user-evaluation evidence into prioritized, testable design improvements and assess what each iteration establishes.
The evaluation and improvement cycle
Evaluation improves an interface when a team uses observed evidence to make focused design changes and then checks whether those changes address the problem. The process is iterative: collect evidence, prioritize findings, make a change, and evaluate the revised design.
A successful test provides evidence about particular users, tasks, and conditions. It does not prove that the interface works for everyone.
From observations to findings
Keep what happened, what it suggests, and what to do about it distinct. An records an event: for example, a participant enters a discount code in the search field and then asks where to apply it. A interprets the evidence: the checkout page does not make the discount-code entry point easy to locate. A possible design change is to make the control more visible and label it clearly. That proposal is not itself a .
Keeping these categories separate helps prevent a team from treating its first design idea as the only solution. Reviewing notes soon after a research round and discussing them with observers can help identify patterns, reduce reliance on individual impressions, and clarify what to change or investigate next.
Record enough context for a to be acted on: the task, what the user did or said, where the difficulty occurred, whether the task was completed, and relevant participant or access needs. Do not turn one person’s experience into a claim about every user. A small usability study can reveal useful problems, but it cannot by itself establish how common those problems are across an entire population.
Prioritizing evaluation findings
Teams often discover more issues than they can fix at once. Prioritize according to the harm a problem causes and the importance of the affected task, rather than only how noticeable the issue is or how easy it seems to fix.
Consider these factors together:
Impact: Does the issue prevent task completion, cause an incorrect result, or create substantial effort or confusion?
Frequency and reach: How often did it occur in the evaluation, and how many users or important journeys might it affect? Treat frequency in a small study as an indication, not a population estimate.
Recovery: Can users recognize and recover from the mistake, or does the problem trap them or lead to a costly consequence?
Accessibility and inclusion: Does the issue create a barrier for people using assistive technology or different input methods? Consider such barriers alongside usability findings. Check accessibility against relevant standards as well as with users; user testing alone cannot establish .
Confidence: Is the supported by repeated behavior, clear evidence, or other sources such as support requests or service data? Is more research needed before making a substantial change?
A can make discussion more consistent. For example, a team might define a problem as critical if it blocks an essential task, major if it makes the task difficult or error-prone, and minor if it causes limited friction. Define the chosen scale and apply it consistently. Frequency, impact, and consequences are common factors in assessing severity, but ratings remain aids to judgment rather than objective measurements.
A practical priority list can distinguish issues by their evidence and consequences:
High priority: Several participants search in the wrong place for the discount-code field and some give up. The issue blocks a common checkout goal and can affect completion.
Medium priority: Participants hesitate over an unclear order-summary label but complete the task. The label creates uncertainty, though users can recover.
Low priority: A decorative icon is slightly misaligned, with no effect on task completion or understanding. It is a cosmetic issue with little user impact.
The exact priority depends on the product’s users and goals. An infrequent problem can still need urgent attention if it blocks an essential task or affects a group facing an access barrier.
Turning findings into design changes
For each high-priority , write a concise problem statement grounded in evidence. Ask what users are trying to accomplish, what in the interface is getting in their way, and what change could address the underlying cause. Do not assume the first proposed fix is correct.
For example, users may overlook “Apply discount code” because it is visually subordinate to unrelated links. The problem is that users who have a code cannot reliably find where to enter it. A could be: if the code entry is labeled plainly and placed near the order total, users will find and apply it more easily.
Test that hypothesis by asking representative users to complete checkout with a supplied code. Observe whether they find the control, apply the code correctly, and understand the updated total. A useful recommendation states what to change, which it addresses, and what outcome to check, so the result can be compared with the original problem.
When evidence is ambiguous, the appropriate next step may be a targeted research question rather than an immediate redesign. Sharing findings with the team can help inform design decisions, work priorities, and future research.
Testing iterations and understanding
Evaluate a proposed improvement in a prototype or working interface, and match the evaluation method to the question. Task-based usability testing can show whether people can complete a journey. Accessibility checks and testing with people with disabilities can expose barriers that general usability testing may miss. Automated checks and expert review can contribute evidence, but should not replace evaluation with users where that is needed.
A useful iteration proceeds through these steps:
Choose a priority question. For example: “Can users find and apply a discount code without help?”
Make a focused change. Keep it small enough for its effect to be understood.
Prepare realistic tasks and an accessible test setup. Check the prototype and test materials before sessions begin.
Observe behavior. Note task completion, errors, hesitation, misunderstandings, and recovery—not only whether participants say they like the design.
Compare evidence. Check whether the original problem still occurs and whether the change introduced new problems.
Decide what comes next. Keep the improvement, revise it, investigate further, or address a newly discovered issue.
For example, making the discount-code field more prominent may help users find it, while a follow-up test could reveal that the label “Promo” remains unclear or that applying a code does not visibly update the total. The next iteration should respond to the remaining evidence rather than assume the first change solved the whole journey.
An interface has for a particular purpose when relevant evidence supports the claim that it works for the intended users and tasks under the conditions evaluated. This claim is bounded: it does not guarantee success for every person, device, context, or future change. Revisit important journeys as the service evolves and monitor research and performance evidence for issues that emerge later.