Usability

I'll start with an example from Bruce Tognazzini that I used for a short talk on usability at BOSC 2002. [start]

Those slides show that it isn't always easy to make a usable program. Developers and users may have different expectations. But a good way to find and clarify those two is through testing and iterative development.

I think of computer programs as having three basic components: the machine resources (including memory, performance, and bandwidth), the underlying model (accounts receivable, quantum mechanics), and the usability. Usability sits at the interface between humans and computers. Most often you think about the usability of application GUIs and web pages, but command-line programs, software libraries and programming languages are all parts of HCI ("human-computer interaction").

Hardware people and materials scientists have done a great job in making computers go fast but that's only part of what's needed to maximize human performance. (I won't cover that link.)

There are many aspects to making something usable.

Usability is a combination of factors that affect the user's experience with the product or system, including:

Ease of learning How fast can a user who has never seen the user interface before learn it sufficiently well to accomplish basic tasks?

Efficiency of use Once an experienced user has learned to use the system, how fast can he or she accomplish tasks?

Memorability If a user has used the system before, can he or she remember enough to use it effectively the next time or does the user have to start over again learning everything?

Error frequency and severity How often do users make errors while using the system, how serious are these errors, and how do users recover from these errors?

Subjective satisfaction How much does the user like using the system?

Usability engineering means trading off these different factors along with restrictions placed by the available factors (hardware, software, developer expertise).

Warm-up exercise

To get started, here's the requirements document for a program, based on an example in Jef Raskin's The Humane Interface.

You work in a lab with Americans and South Africans. Americans use the old British system for weights and measures while South Africa, like just about the rest of the world, uses metric.

At times you get asked "what's 82 Farenheit in Celsius?" or "what's 25C in F?" In fact, you're the lab expert at it so you get asked that question a lot. To make things easier for you you ask a programmer friend to write a program for you to help you convert from one to the other.

Your friend is a great programmerand can implement anything you want, but won't design it for you. You need to come up with the interface for a computer program that converts from C-to-F or F-to-C. If important it only needs to handle the range -40C to 125C and the equivalent range in F, and only down to 0.1 degress. That is, possible numbers to convert are 20.1F, -10C, 0.5C and 120.9F but not 92.56C nor -273.15F.

For this exercise you may work alone or with one other person in coming up with a design. Sketch it out on a piece of paper and be prepared to present your design to the rest of the class. I'll take a picture of the design so others can see it. In your demonstration you'll need to demonstrate how you would use the interface to:

convert 82F into C
convert 25C into F

Be creative in coming up with a usable interface. There are many ways to solve this problem.

Requirements

The first phase in a project is to develop a requirements document. I'll walk through the slide by Rachel Smith to describe this in more detail. There's an associated PDF with a more details.

Requirements gathering means you need to talk to the many classes of users to figure out what they want. I'll go through some of the ways to collect that data. Note that users don't always know what they want, but might think they do.

I'll elaborate on scenerios and persona development as parts of the requirements document. I'll start with a summary then use Rachel's slides on the topic (PDF and PPT).

The persona development methodology is elaborated upon in Alan Cooper's The Inmates are Running the Asylum. The major point of that book is that software developers are not typical users and personas help separate and clarify just who "the user" is. Not everyone uses that methodology.

For an example of a real requirements developed along these lines see the Pachyderm document archive, and more specifically the Pachyspec 1.5.

Here's another product specification. This uses a rather different style. It's written by a programmer and has more specification of the internals. Your project may have both styles of documents, and more.

Extreme programming uses a related technique called user stories to relate features to specific scenarios.

Testing

How do you tell if you've succeeded? How do you compare one design with another?

You can't improve what you can't measure. There are many aspects of usability that you can measure. An important one - "given the goal X, how long did it take to achieve the goal?" A good source for test cases is to use the scenarios developed in the requirements document.

I'll go through some examples of tests for various web sites.

You cannot use yourself as a test subject. You don't need to test that many people. Even one or two is good, but 3-5 works is a good trade off.

I'll go through some more information about usability testing.

Tognazzini has a nice summary of how testing saves money (and time) during the development process

Problems are fixed before the product is shipped, not after.
The team can concentrate on real problems, not imaginary ones.
Engineers code, instead of debating.
Time to market is sharply reduced.
Finally, upon first release, your sales department has a rock-solid design they can go sell without having to pepper their pitches with how it is all going to actually work in release 1.1 or 2.0.

(Yes, that's stated in commercial terms. Instead of saying "sales department" you could say "principal investigator".)

Some mistakes to watch out for. An important one - don't blame the user!

Iterative design and paper prototypes

Designs must be tested. The results of the tests can be used to make a new design. This design should also be tested. The cheaper and faster it is to develop and test a design the more likely the result will be usable.

It's too expensive to develop a complete program from scratch in order to do a handful of tests with it. "Mock-ups" are better. These provide an idea of what the result will look like, without actually working. A mockup might be a web page that lets you enter data but takes you to the same results page no matter what you entered.

Even that's expensive and potentially misleading. People might think there is actual working code.

Instead, develop on paper. Here's a paper prototype I developed for one client. Some better example of paper prototypes.

You can "run" most of the usability tests using a human as the computer. Just like the old days. Sometimes called a "Wizard of Oz" testing.

Paper prototypes let you design and test several versions of the program in the same day, help drive consensus on the people involved in the development, and are cheap.

Evaluating designs without users

Some low-level tasks can be done even without users. One is the GOMS model.

Here are numbers from the accompanying handout

keystroke (.12-1.2 sec; .28 recommended for most users)
T(n) - Type a sequence of n characters on a keyboard (n * K sec)
P - Point with mouse to a target on the display (1.1 sec)
B - Press or release mouse button (.1 sec).
BB - Click mouse button (.2 sec).
H - Home hands to keyboard or mouse (.4 sec).
M - Mental act of routine thinking or perception (.6 - 1.35 sec; use 1.2 sec).
W(t) - Waiting for the system to respond (time t must be determined).

I'll use them to evaluate a few of the temperature converter examples.

The handout mentions compares a mouse vs. a "power key" way of deleting a file with the conclusion that the power key is faster for experienced users. Compare that to what Tognazzini said.

Another model is Fitts' Law which models how long it takes to select something with the mouse. See this self-test and try out this web-based test.

Designing the interface

There are various guidelines on how to develop a GUI and web pages. I can only provide a few ideas on the usability part and will have to ask you to look elsewhere on how to make the result actually look good. I am not an artist.

Affordances

I'll talk about affordance as used by Donald Norman. Based on his The Psychology of Everyday Things I'll talk for a bit about doors.

Consistency

Norman's biggest point is that the interface should follow conventions and fit the user's model of how things work

How new users understand what to do: Four principles for screen interfaces

Follow conventional usage, both in the choice of images and the allowable interactions
Example: scrollbar.

Use words to describe the desired action (e.g., "click here" or use labels in front of perceived objects).

Use metaphor

Follow a coherent conceptual model so that once part of the interface is learned, the same principles apply to other parts.

More guidelines

I'll go through Tognazzini's more complete list of usability guidelines.

There are many more beyond this. For example, the US government has guidelines on handicap accessibility - eg, recommendations so that web sites are usable by people who are are blind or have very poor vision.

Exercise - microwave oven

Your project for the rest of the day is to design controls for a microwave oven. It will be a standard model for use in a consumer kitchen. In this example you are a typical end-user so I'll skip the persona development.

Here are the requirements:

Enter a specific cook time ranging from 1 second to 45 minutes
Choose a power level ranging from 500W to 1500W.
Allow "quick start" options to reheat pizza, boil cup of water (as for tea or coffee) and to cook a frozen entree.
Show some indication of much cook time remains.
When the user opens the door the oven will stop (this occurs automatically as part of the safety system). Government regulations state that oven must not restart (after the door is closed again) without some explicit user control. Include this control.

You will develop this in a team of 3 or 4 people.

Do not look at an existing microwave oven to see how it works.

The specification here is incomplete. I'll give you about 20 minutes to think about the idea and come up with questions you need answered in order to do your design. You all will ask me those answers and I'll be the oracle that provides the answers from market research. I will not provide any answers from user tests.

Your team will develop test scenarios for each of the requirements. These will be used to evaluate your designs.

Your team will develop several versions of the microwave oven interface. You should use the GOMS model and Fitts' Law as guidelines and do in-group testing of each version.

For each design make a paper prototype and carry out the tests. Time each test and use the results to select the best two designs.

After about an hour I'll have you test the interface using people from another group. You will have them perform your test cases. Time how long each one took and keep track of any problems in your interface.

Once testing is finished you will redesign your interface to fix any problems that arose. There will be another round of testing to see if your design improved.

Feedback from marketing:

The only needed power levels are 500, 800, 1000 and 1500 Watts.
Users want 1 second accuracy if the cooking time is under 1 minute, 5 second accuracy if the cooking time is under 5 minutes, and 15 seconds for the rest of the range. It must not have a resolution under 1 second. It may have a 1 second resolution for the whole range.
There's no requirement to enter the weight of the food
"entree" means T.V. dinner. Guess "entree" is a US-term.

CHANGE IN PLANS!

Great news - we did some more research and found we can make an extra R25 million if we add a few new features. We'll need to add a clock display and a timer to the oven and a couple more "quick start" options.

The clock must show the current time ~~(the oven will get the time from the mobile phone network so there's no need to set it).~~ My marketing looked over their notes and found a mistake. Enough people will need to microwave in the middle of the Karoo that we'll have the user be able to set the time. The mobile phone network idea was wrong. When cooking there's no need to show the time.
The timer must have the same resolution as the normal cook timer. When the timer is running there's no need to show the time. The timer will not be used when the microwave is cooking.
There must be quick start option for 30 seconds, 1 minute and 2 minutes.

Ease of learning	How fast can a user who has never seen the user interface before learn it sufficiently well to accomplish basic tasks?
Efficiency of use	Once an experienced user has learned to use the system, how fast can he or she accomplish tasks?
Memorability	If a user has used the system before, can he or she remember enough to use it effectively the next time or does the user have to start over again learning everything?
Error frequency and severity	How often do users make errors while using the system, how serious are these errors, and how do users recover from these errors?
Subjective satisfaction	How much does the user like using the system?