Confusion As A Usability Defect

As a software engineer, you should always be looking for the location of the next defect or at least clues that something is wrong. The problem is that most developers have been trained to wait for feedback from the QA team. In many cases, the QA team is following a script or has been trained on how to use the system, so some clues get lost in the familiarity.

Michael Bolton has an interesting post regarding confusion as an oracle:

James peered over his glasses. “When you’re confused,” he said, “that’s a sign that there’s something confusing going on. I gave you a confusing product to test. Confusion might not be fun, but it’s a natural consequence when you’re dealing with a confusing product.” James was tacitly suggesting that Jon’s confusion cound be used as an oracle—a heuristic principle or mechanism by which we recognize a problem.

When the QA team is confused, that points to potential issues and should be used as a heuristic. The confusion could be from a few sources. First, the test script could be out of sync with the user interface in such a way that is not obvious how the tester should proceed. This can happen with any application that is evolving throughout the development lifecycle. Second, you could have someone that has not been trained on the application as the tester. This can quickly be remedied by providing the appropriate information on how to use the application. It could also point to an incomplete test script, meaning someone new cannot execute the test script without additional instruction.

Another reason the QA team could be confused is because the application is confusing. This is not a good sign and should be seen as a warning to the development team. Most likely there is a usability defect in the application. For some teams, usability defects do not exist and usability issues get added to the list of things to do. This is a big mistake when developing web applications. Almost a year ago I wrote about Krug’s usability rules:

The first two Krug rules of usability are very related:

  1. Don’t make me think – as far as is humanly possible, when I look at a web page it should be self-evident, obvious, self-explanatory.
  2. It doesn’t matter how many times I have to click, as long as each click is a mindless unambiguous choice.

I love the “don’t make me think” rule. If you design your application with this rule in mind, you will get past most usability problems. However, if you are a startup and developing for a large userbase, you may have slightly more concerns. Mark Evans wrote recently about a rule of thumb “I get it”:

But if you push aside the entrepreneurial enthusiasm, a startup’s success prospects depend on a compelling idea and, as important, the ability to quickly get potential users to say “Yes, I get it”. This means being crystal clear what the service or product does, and the value propositions/benefits being delivered.

The product/service needs to fill a need or convince users it meets a need they didn’t know they had. Getting users on board has to be user-friendly and efficient. And the product/service has to delight.

If you are following these basic principles, your product should not be confusing. I am a big believer in making things simple for users, because it means they will enjoy (or at least not hate) using the system. This is obviously a good thing, but more importantly, users will look for other ways to use your application.

So, why should a “confusing” application have usability defects tracked? If an application is confusing, that means it is going to be difficult to use. When an application is difficult to use, people stop using it because they can not see the benefits to using the system.

Usability is also hard to define, but if you look at Krug’s rules you will see that the user should not have to find the right thing to do, it should be fairly obvious. But, what about prior to production? You don’t have typical users on the system, so how do you determine usability? One thing I have seen is that the length of the test script can be a good trigger for something being too difficult.

Let’s assume you have manual testing being completed. Ignoring the test case setup instructions, how many steps are required to test one feature? This is similar to the number of clicks heuristic, but it is the number of actions a user must take in order to complete a task. You could say the number is something like 7 but that is not entirely useful. I have used “Why” as my metric of choice. If you ask “why do I need to complete this step?” and there is no obvious or definable reason, then you likely are introducing unnecessary steps to the task. If you can eliminate these issues, your application usability should improve.

To really make your application simpler, make sure your QA team starts questioning things in the beginning of the process. Someone writes the test script, and it could be the QA tester themselves. The developer and the tester should go through the test script and ask “why” for each step. This will proactively remove any stumbling blocks in the plan and have a much more usable system after it passes QA testing.

Are there any tips or tricks you have for improving usability?

Enhanced by Zemanta

4 thoughts on “Confusion As A Usability Defect

  1. It’s funny, I just wrote about something similar. I didn’t quote Krug there, though I probably should have given my admiration for his ‘Don’t Make Me Think’ philosophy.

    I hadn’t seen the ‘I get it’ piece, so thank you for directing me there. I agree with almost all of those points, short of the ‘delight’ verbiage which just irks me and often gets in the way of other development.

    The two things I do that sometimes help with usability is viewing with styles off and the five foot test. In the first I simply turn off all styles on the website during my walk-through. Now this doesn’t always work but it often helps to expose areas where things have been over-designed and are not clear at the basic level.

    In the second, I take a few steps back from the computer screen until I’m about five feet away. I then look and see if I can understand what that page is about and what I should do next. If I’m unable to do that, I start to get concerned.

    There are more, but those are two ‘fun’ ones that often lead to interesting dialog.


    1. AJ

      I have heard of the 5-foot test before, but that is definitely more design focused than I am thinking. I tend to focus on the application development side of things given my developer background. I have not heard of turning off styles though. What value or insight does it provide (honest question)? I would think that styles are required to really “see” the application correctly given the way that navigation is typically styled.


  2. Rob,

    Nice article. Re. turning styles off, I think that this tip may relate more to checking the accessibility of a website rather than its usability per se (and even then, it’s a quick-and-dirty technique, but interesting nonetheless).


Comments are closed.