Fix the three worst problems, not the whole list

A usability audit with sixty findings feels thorough. In practice, most of it is never fixed. The team picks the easy items, the important ones wait for “the redesign”, and six months later the same people get stuck in the same places.

The alternative is simple and a bit uncomfortable: after each round of testing, choose the three worst problems, fix only those, and test again.

Why three

Three is what a small team can fix before the next round. It forces a decision about what matters most, and it keeps each round short enough to repeat. Repeating is where the value is: every round removes the problems that were hiding the next ones.

How to rank what you saw

For each problem, ask two questions:

1. How many people hit it? One person out of six may be an accident. Four out of six is a pattern.
2. What did it cost them? A moment of hesitation is minor. Giving up on the task, or completing it wrongly, is severe.

Problems that many people hit and that stop them completely go to the top. Everything else goes on the list for later. Do not rank by how easy the fix is; that comes next.

Find the smallest fix

For each of the three, look for the least change that removes the problem. Not the best possible solution, not a redesign of the section. Often it is a word, a label, a moved button or a missing piece of information:

• People cannot find prices: show a “from” price where they already look.
• People miss the main button on mobile: move it directly under the form they just filled in.
• People do not understand an icon: add a text label next to it.

Small fixes ship this week. Big fixes get scheduled, discussed and diluted. If the small fix does not work, the next round will tell you, and you will have lost very little.

Write the fix so someone else can do it

A good fix description has four parts: the evidence (who got stuck, where), the change, a way to check it worked, and what must not be touched. UX Surgery writes this as a Markdown “fix prompt” that you can hand to a developer or paste into a coding agent. The same structure works on a sticky note.

Then test again

Run the same tasks with the same kind of people. Did the three problems go away? Did the fix create a new one? Keep the history, so you can see progress over months instead of arguing about it.

See how this looks in a sample report