Usability
You can observe a lot just by watching.
—Yogi Berra
Usability is a matter of ensuring that users are successful in achieving their purpose at your site.
"Usability is the measure of the quality of the user experience when interacting with a web site. Usability has two roles: to set the direction for the design and to check that the design works. The second has gotten the most attention since it is the simplest: just run a user test of any Web site and you will quickly have a long list of things that must be changed to make the site easier to use. But it would be better if we didn't get these problems in the first place, and that's why usability also needs to set the direction for the design."
—Jakob Neilsen, quoted from an interview with Publish.comThe usual breakdown in thinking comes when we think 'usable' means 'looks exactly the same.' That's the hurdle most people have to overcome. To me, 'usable' means 'the content is readable and easily understood.' The page can look a little less sophisticated in a six-year-old browser—that doesn't strike me as a tragedy.
—Eric A. Meyer, quoted from Transitional Layouts in (X)HTML and CSS
University website from xkcd.com
Why use a usability test?
So that everyone on the development team knows as much about the user's needs as they can. A usability test is one of a series of checks intended to keep a project on course. Three things to remember about usability:
- It's not about you, it's about the user.
- Test to learn, not to prove you're right.
- Test, redo. Test, redo.
What are you testing?
Users need to be given specific tasks to accomplish during the test. In a Web site test, students might be asked to go to the new Consumer Studies home page and find Belinda Orzada's e-mail address (easy) or course descriptions for Apparel Design (hard). In an authoring application test, users might be asked to find (without the help of the flow chart, of course), where to practice principle 4. In testing for comprehension, users could be asked to navigate through an entire principle until they could explain the underlying concept.
Who does what during a test?
Users: The student performing the test moves their finger as they would a computer cursor and touches the work area to see what response the "computer" provides for that item. Any typed input that is required is written on removable tape or transparency. End users with no prior exposure to the material are the best participants for testing. Having two students tested at the same time can be an advantage over a single tester. Two students engaged in co-discovery can explain things to each other and provide contrasting points of view without as much prompting from the facilitator as a single user may need.
Facilitator: Hosts the test and, when following the guidelines closely, is the only person allowed to talk to the user during a test. The facilitator encourages the user to continually talk about their thought processes for the choices they are making. Questions such as "what are you trying to do?" and "what did you expect would happen when you clicked that button?" can provide insight without affecting the students perception of the product. It has been found that results of potential inquiries from the group become self-evident after the user continues to work without having to interrupt the user. The facilitator indicates when a task has been completed.
Recorder: Takes good notes. Anyone who watches usability tests needs to note user actions or vocalizations—but not the note-taker's opinions of what these actions mean. Questions to consider include: Did users expect a function to behave differently? Did users take a round-about route? Which clues were understood, misunderstood, or missed completely? Did the students notice when they made an error, and, if so, how to recover from it? It's useful to keep a record of changes made between iterations and the rationale behind them.
Computer (two people): No helping -- just process the user's command exactly like a good computer would! Although it may be possible to generate some computer feedback on the fly, the real intention is to test an existing design. We want to understand the problem the students are having. If an observer helps or gives hints, we can lose the opportunity to understand how the user thinks.
What does the computer "screen" look like?
A work table is set up to simulate a computer screen. Separate pieces of paper are created for each drop-down menu and dialog box, and in this case, for each box on the flow chart. Post-its for perpetual items like navigation bar icons are arranged around the informational area of the display. As a student "clicks" on an item on the simulated screen, a portion (or all) of the screen is replaced with new information and choices.
Suggestions for constructing a paper mock-ups include: cardboard, unlined index cards, colored markers, removable tape, scissors, transparency film, highlighters, glue stick. We are more concerned with testing the product's "feel" at this point rather than its "look." The clarity of icons and screen real estate issues can not be accurately assessed at this point.
What happens after a test?
There is a debriefing period where questions are asked and observations are clarified. A single test will generate some initial information but the test would ideally be offered at each major iteration of the design. A design cycle does not imply coding the next completed version of the application. These tests should help contribute to short iterative cycles that are completed offline before major coding effort is invested. It's possible to test several designs during one session with the same user.
[Based on the one-day course, Product Usability: Survival Techniques, from User Interface Engineering.]
Bentley College has a Design and Usability Center offering a Usability Boot Camp.
