Software usability. What the heck is that? Is it the same as software ease of use? Didn’t that used to be ‘user-friendly’ software? And what sort of person has the skills to create this easily used software? Is it a software ergonomist? Is a human-computer interaction specialist better than a GUI designer, and who charges more?
And does anyone really care?
I certainly don’t care — not about the labels, anyway. As a user what I care about is, after working with the software for 15 minutes, do I feel an uncontrollable urge to put my fist through the screen? If so, the software probably isn’t that easy to use. That’s my definition. (Although it’s a sliding scale — maybe I only want to slap the CPU around a little, or publicly embarrass the hard drive. Frustration is subjective.)
That said, what if you’re not the user but the software designer/developer? What does it matter to you if I’m continually grinding my teeth because of all the little quirks and foibles you’ve thoughtfully included in your software? Why should you waste resources fixing these problems?
Well, consider this scenario: I have a choice between buying your software or a competitor’s. While they have different features and functions, chances are the core capabilities are roughly the same. But, because your software is annoying and frustrating to use, I’m going to buy the competitor’s — if only to save the cost of replacing the monitors I keep punching.
“Aha,” you say, “but mine is the only product in its niche — my users have to buy it. Why should I spend the resources on making it more usable?”
Sadly, that’s a common argument. And it works, too, right up until a competing product becomes available, or until it is time for your customer to renew your services contract, or you produce another product and, oddly, you create no customer loyalty. I’m not even going to mention the cost of customer support and service when your users can’t figure out how to do their work.
I think I’ve made my point. And if not, consider this: everyone else is doing it — you want to be one of the cool kids, don’t you? Over the next three issues, I’m going to lay out the basics of running a software usability testing session. After reading these articles you will not, by any stretch, have the skills and knowledge to be a software usability specialist (heck, they have whole weekend seminars for that sort of thing — though some people get by with a university degree).
What you will have is an overview of the basics, an explanation of some of the issues that often aren’t covered in the books or seminars, and a general de-mystification of the process. Sort of like the Secrets of the World’s Greatest Magic Tricks Exposed, except without all the scantily-clad assistants.
These articles will cover the three phases of the basic usability testing session: finding appropriate users for testing, setting up the session and running the session. Just this simple knowledge can carry you pretty far. There are a lot of different types of sessions you can run with essentially the same basic pattern — paper-prototype tests, alpha-level tests, and so on. I’ll lay out the processes in a way that can be implemented by you, right now, with the equipment and skills you have on hand.
So be prepared to clip and save these articles. When you put them all together, you’ll have a fine little book on usability testing processes. Well, maybe not a book — more like a pamphlet. Okay, really more like four newspaper clippings stapled together.
But it will be easy to use.
Blau is a software designer working in the User-Centered Design area at the IBM Toronto Lab. He can be reached at ablau@ca.ibm.com.
