Problem Statements

My close personal friend, Jeff Rubin (what up, Jeff!), wrote a book once. You may own it. Conveniently it is called, “Handbook of Usability Testing.”

In the book Jeff talks about usability objectives. There are two types and the first I will write an example to illustrate.

The user will accomplish task X, in n seconds, with n error(s) or less.

Pretty simple, yet rather formal. Remember, we are writing our usability objectives during the requirements gathering stage of the project. A usability objective is a user requirement after all. And with the above example, I usually add something like, “Subsequent attempts will show an increased improvement in fewer errors and less time spent on the task.” Or something like that. That is the learnability part. If not intuitive enough, how learnable is the task?

The second type of objective Jeff writes about in his amazoning (sp?) book is the problem statement. Simply put: will the user be able to accomplish the task? Well, it’s really more of a question, but you get the idea. Problem statements are best used during front-end (exploratory) testing. Though I find them very useful when you are a bazillion (it’s a number now) constraints. Constraints that may cause you to do some heuristability.

The only thing to identify beyond the problem statement is how many people, or what percentage or the user population, is it acceptable to have not be able to complete the task? Your business partner should be able to help you with that. Just remind them that 20 percent of 79,000 is a lot of people. But, once you set your decision threshold, all you have to do is test and observe the participant completing or not completing the task. That’s it. Tally up the totals and if you are above the “we need to do something about this” line, you are done.

To be honest, I do spend more time testing problem statements that usability objectives. I mean really, if you want to write an objective that takes timing into account, shouldn’t you then also look at your user group and ask, “How much time are we asking our user group to spend on tasks each day, and then how does this objective fit into that.”

After countless projects which write usability objectives in the first format I mentioned, I have to wonder how many minutes each day my company asks its employees to spend on tasks. Well, about 8 hours worth you might say. But if you added up all the objectives of all those past projects, my guess is that you would have more than 8 hours of work. So what are we trying to accomplish by having a user make it through a task in under 2 minutes?

It depends I suppose. But overall I would say not much. So few interactions are dependent on timings. Yes, we would like them to finish the task in two minutes, but is it a real usability issue when it takes 3 minutes? I’d say not, depending on the interaction. You’d want a tank gunner to be able to find the trigger pretty quickly, but completing a rate quote? Meh.

This question goes back to being guest poster last July on SvN: do you write usability objectives? If so, how, who uses them, who helps you decide what the limiting factors are, etc. Inquiring minds and all.