After you’ve done usability testing, or got user feedback of any kind, what should you work on? Most people prioritise low-hanging fruit. Clients ask me if there are “quick wins”.
But a better question to ask is “What is most broken?” During the usability testing, what caused the biggest problems for your users?
Don’t conflate low-hanging fruit with what Steve Krug calls kayak problems — issues users may initially struggle with, or complain about, but can quickly recover from. Most-broken issues, by contrast, are show-stoppers.
I recently conducted testing for on an online life insurance application. A link on the web form prompted participants to enter additional occupations — before they’d answered all questions about their main occupation.
For technical reasons (apparently), changing the position of this link was a big headache for the developers. Multiple tests and customer feedback reports showed it was the most problematic item — most broken — for users. Common sense suggested the form structure didn’t match real-world conversational structure. But the developers pushed back — for them, this wasn’t low hanging fruit.
Yet, fixing other easy stuff was not going to make this problem go away.
The Problem with Hard Fixes
The problem with hard-to-fix stuff is that, well, it’s hard to fix. That doesn’t mean you should avoid it. If it’s most broken, you’ve got to tackle it eventually, but you won’t reap the benefits of the usability testing. The project may lose momentum. A lot of hard to fix items get put into a box marked “later” that no-one wants to open.
Everyone Wants the Low Hanging Fruit
Everyone wants to find easy stuff to fix, for obvious reasons. While editing a label or swapping buttons around is easy to implement, the effect on user experience is often equally minor.
When Small Changes Solve Big Problems
After conducting usability research, look out for things that are most broken, which can be easily remedied. These are the things you should fix first.
Example I once did usability testing for a new online savings account aimed at seniors. At the end of the process, there was a captcha. The captcha had no label — no “enter the letters and numbers you seen on the screen”.
One of the participants didn’t understand what to do next. She gave up, despite having gone through the long (and painful) form. The captcha was a show stopper, but there was an easy fix — add a text explanation to the captcha, or (better) just remove the captcha.
Another well-known example of problem solved with an easy to implement fix is the story of the $300 million button.
1% of each $300 million saved as a result of this article can be sent to my PayPal account 🙂