Ever wonder why you keep encountering the same usability problems on the websites and apps you use?
Sure, many organizations don’t conduct usability tests on their products, but many do, what explains the persistence of such problems?
Finding and fixing usability problems is one of the most effective ways for improving the user experience on websites, applications and hardware. But just because a problem is identified in a usability test doesn’t mean it gets fixed.
While this may seem perplexing, there are usually good reasons. Here are seven reasons why usability problems often don’t get fixed.
- It’s unclear how many users will actually encounter the problem: Identifying a usability issue is the first step but knowing if a problem affects a few or a lot of users helps product stakeholders prioritize efforts. Without any sense of frequency, it’s easy to assume the problem doesn’t affect a lot of users–especially if it was uncovered in a small sample usability test.
- Only a few users will encounter the problem: One of the reasons for determining the rate at which a usability issue occurs in the entire user population is so that product owners can make the best decisions with their limited resources. If a problem doesn’t impact a lot of users, it gets a lower priority. Of course, if you see a problem in a small sample usability study, the problem is much more likely to be a common than uncommon problem. You can place upper and lower boundaries on frequency estimate using confidence intervals. For example, if you observe a problem that 5 out of 5 users have in a usability test, we can be 90% confident at least 70% of all users would encounter the problem. Compelling evidence to fix right?
However, it’s possible that the task we’re testing is not common or the part of the interface is more obscure. You could be identifying problems with tasks that only 10% of the actual population uses. Usability studies are good for finding problems but don’t necessarily produce the final word on actual problem occurrence when taking into account the entire application. That’s one reason we strongly advocate a top-task analysis. Showing that a problem impacts a high-frequency task makes a more compelling argument for fixing it.
- There’s disagreement on whether it is a usability problem: For as long as there’s been usability professionals, there’s been usability professionals who disagree on what a usability problem is. And that holds even if experienced practitioners watch the same users attempting the same tasks. If us experts can’t agree, you should expect that product developers won’t agree that all the problems we identify are legitimate issues. They’ll often want more evidence of the frequency or impact of the issue. We find this is especially the case with problems identified in heuristic evaluations. While heuristic evaluations are an effective discount usability method, the results are often met with a skeptical reception. How do we know it’s a real usability issue if no users were actually observed having an issue and instead we rely on the expert opinion?
- It will require some major work: On the surface they may seem like easy problems to fix, but often “cosmetic” changes go deep into platform changes or redesigning major flows. When we see problems in the checkout flow on ecommerce websites, changing things like the order of the fields or whether the user is required to register often requires a major rework in the architecture, unfortunately. Often problems will get addressed when major changes are made–which sometimes can take a long time.
- The impact isn’t that detrimental on the experience: Problem severity and problem frequency are different things. A trivial issue can affect a lot of users and a severe issue can impact just a handful. Even if it’s shown that a lot of users will likely stumble through part of an experience, if they are able to recover and get through, it’s not as severe a problem when compared to an experience where users fail, get wrong information, or abandon the application altogether.
- The perceived effort outweighs the perceived benefit: Even when the frequency and severity of a problem are well understood and agreed upon, it just might take too much development time to fix. This is even the case if the effort is small. The same effort might be better spent developing new features or fixing other higher priority issues. Every development organization has a long list of “nice-to-have” fixes, and they can add up over time. It often makes better business sense (at least in the short-term) to address high-profile issues or add new features than address a litany of easy to fix minor issues.
- The website or product works and is making money: If someone wants to use or purchase something badly enough, then they’ll deal with a lackluster experience. No application will be bug-free or free from usability issues and making changes to code risks introducing new problems. You could call this the “If it aint broke enough, don’t fix it” attitude. A good example of this is the Enterprise rental car website. Enterprise offers competitive pricing and generally above average customer service. It’s even been the subject of some high-profile examples of excellent customer service. Yet the website contains many usability problems. For a few years we’ve used problems uncovered on Enterprise.com in our classes and at our UX Bootcamp. Many students are amazed to see that despite some fairly obvious issues, they still remain to this day.
I had a chance to speak with one of the website professionals that works with the parent company of Enterprise in 2011. He said that they are aware of many of the problems and do want to fix them. But as he put it, the website is making money and has been for a long time. A major redesign and platform change are planned but it doesn’t make business sense to exert the effort when an entirely new interface will replace any changes…eventually.
