User-centered design for IT services: The usability toolbox, part 2

This is the third in a series of articles that introduces user-centered design (UCD). This is the second article in which we highlight a collection of several powerful and easy-to-use techniques for improving the design of any IT product or service. For an overview of the benefits of UCD, see User- centered design for IT services: the low-hanging fruit.

The usability toolbox

There are many techniques that can be used to incorporate user-centered design into your development process [1]. The ones that we suggest in this series are some of the simpler, easier-to-use techniques. Even though they don't require a large investment of time or money, using them can still result in dramatic improvements in your IT products or services [2].

While these techniques can be used together, usually in the order in which they are presented here, we suggest that you think of them as tools in a toolbox. You can pick and choose which tools to use, as appropriate, for each project you work on. If you are new to user-centered design, we suggest starting on a fairly small scale. You may want to use only one or two of these techniques the first time you try them, and build from there in future projects. Trying to do everything the first time can result in information overload and burnout.

This article covers the second half of this toolbox of the simpler UCD techniques.

Task analysis

Task analysis is a process you can use to break down the activities performed in pursuit of a goal, in order to determine exactly how it was accomplished. In web and software design, this process can help you understand users' procedures better, and help you ensure that all required functionality is provided.

Information on users' goals as well as specific tasks performed is usually gathered during user observations or interviews. Goals are the high-level end results that users would like to achieve (e.g., ensure all employees are paid on time), and the tasks are the things users must do to obtain these results (e.g., entering employee information into the payroll system). Goals generally change much less over time than do tasks, which often vary with the available technology. It is important not to design a system to simply accommodate existing user tasks, but to think more broadly about users' goals. Often, a new and better system can be designed by taking a more high-level view of what users are really trying to accomplish.

The first step in a task analysis is to determine your target users' goals, then list all the tasks performed to achieve these goals. These may be tasks users already perform in an existing web or software application. Alternatively, you may wish to study the tasks users are performing in pursuit of higher goals in order to come up with a brand new solution for them. For example, users may currently be doing collaborative writing by emailing files back and forth. If you were designing a new system to facilitate collaborative writing, you would want to first understand how your target users are managing this process with the tools presently available to them, as well as how well these tasks align or don't align with the users' true goals.

After you identify the high-level tasks, break them down further into subtasks. Continue this breaking down of the tasks to whatever level is useful to you as you design the new solution. The level of granularity of the tasks can vary based on the complexity of the domain as well as whether the benefits of looking very closely at a task justifies the costs of such in-depth examination. When cataloging the users' goals and tasks, it is generally best to avoid specifying the technology used in order to avoid making any assumptions about the user interface which will affect the design process.

When the users' tasks have been identified, you can rate them on frequency, importance, and difficulty for each target-user type, usually specified as a persona. Personas are specific descriptions of fictional users of a system (see our previous article in this series, User-centered design for IT services: The usability toolbox, part 1, for more information on personas). These user archetypes are created by talking to and observing real users, and finding patterns based on goals which define each category of user. Personas can help you ensure that the system you are designing meets the needs of specific user types, as opposed to designing a system intended for every possible user that really doesn't work well for any of them.

Using a color-coded chart to illustrate frequency, importance, and difficulty of each task for each persona can be helpful in spotting trends (to view a sample task analysis visualization, go to http://www2.sims.berkeley.edu/academics/courses/is213/s04/projects/EventCalendar/assign2.html#TaskAnalysis). For example, if multiple personas seem to have similar patterns of frequency, importance, or difficulty on many tasks, it is likely that you can combine them into a single persona. These frequency and importance ratings can also give you information on how prominently to feature each task in the interface, and help you ensure that you have included functionality to support all the important user tasks.

When the goals and tasks performed by users are well-understood, it helps you to not only design the proper interface to support them, but often also suggest ways to perform the tasks more efficiently, or even eliminate them entirely and replace them with new tasks that better support the users' goals. A task analysis can help you realize that a potential feature is not truly helpful to your users, or that the tasks can be regrouped or ordered in a way that is more efficient or logical. Finally, the tasks listed in the task analysis are often the starting point for developing user scenarios, which you can use to inform the design process as well as create usability testing tasks.

Heuristic evaluation

A heuristic evaluation is a method for finding usability problems in a user interface by reviewing it for compliance with a checklist of recognized usability principles, or "heuristics". They are traditionally performed by a group of trained evaluators who individually evaluate a system and then combine their results in order to come up with a prioritized list of problems to be fixed. However, we believe that most anyone can use a heuristic checklist in order to spot the more obvious usability problems.

Heuristic evaluations are often used to evaluate an existing application, but you (and other members of your team) can use them during development to make sure you have taken these considerations into account in your system. It is generally best to have people who are not directly involved in the project evaluate the application using these heuristics. (You may want to trade heuristic evaluations with someone else who's working on a project at the same time.) These evaluators are able to look at it with "fresh eyes", allowing them to see potentially confusing things that frequent users of the application have learned to ignore, or that you may think make sense because you understand the implementation model. Evaluators may review the interface by going through it in a systematic way that makes sense to them, or may follow previously defined user scenarios. This is usually determined by whether the goal of the heuristic evaluation is to do a general overview of the interface, or evaluate specific interactions, screens, or use cases. As the evaluators find usability problems, they describe the problem, list the heuristic violated, and rate the severity of the problem, often on a scale of 0-4, from "not a usability problem at all" to "usability catastrophe; imperative to fix" [3]. Usability problems can then be ordered by severity, the proportion of the users experiencing the problem, and the impact of the problem on users who experience it to determine which problems must be fixed immediately and which fixes can be deferred, if necessary, to the next round of development.

Although other heuristics may be useful, Jakob Nielsen has defined the following 10 Usability Heuristics [4], which are usually considered the standard:

1. Visibility of system status
2. Match between the system and the real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, and recover from errors
10. Help and documentation

A good, more detailed checklist for heuristic evaluations can be found on the Society for Technical Communications Heuristic evaluation — A system checklist web page.

Usability testing

Many people think of usability tests as requiring sophisticated rooms with one-way mirrors and recording equipment, with highly detailed tests that take an hour or more to complete, and require even more time to transcribe or understand the results. While there are definitely times where this level of testing is useful, it is overkill for most IT projects. In fact, you can obtain extremely helpful results, and realize great improvements in your product or service, from usability tests done in a few minutes at a user's desk or in the conference room down the hall. As we've mentioned before in this article series, it's best to start small and work your way up.

General user testing tips

Whenever you're running any sort of test with a user, there are a few basic techniques you should follow to make sure that you get the best possible information. These are related to the rules for interviews that we mentioned in the previous article in this series. These techniques include:

• Think aloud. Asking a user to think out loud as he or she proceeds through the test can help reveal confusing portions of the interface as well as give you a sense of what features, wording, or help the user is looking for when they do get stuck. It's OK to remind the user to continue to think aloud if they become quiet, but try not to interrupt their train of thought — wait for a natural pause.

• Three to five users are enough. Unless you have multiple distinct groups of users of a system with very different needs or behaviors (e.g., a system where staff are interacting with an administrative interface while students are interacting with the user interface), getting just three to five users to participate in a usability test will generate very useful data. In the case of multiple groups of users, it's helpful to have three to five users from each distinct group. If your resources allow and by the fifth test you're still learning lots of new things from each user, you may want to continue testing additional users until you realize you're no longer discovering much new information. However, if you have the time and resources to run more than five tests, it's often more helpful to test successive iterations of the product with small numbers of users than it is to test one iteration with a large number.

• Don't help. The idea of a usability test is to see where the user would run into difficulty with a system if they were using it on their own, and to get the user to express his or her own opinions. If you help, you're (obviously) not going to get this data. Nonverbal cues (smiles, sighs, glances, etc.) can be just as "helpful" as explicit instructions — try to remain as neutral as possible as the user performs each task.

• Distance yourself from the product. The user will be less likely to give you honest feedback if you ask them to test "this program I've slaved over for the past few months" than if you ask them to test "this program that I've been asked to gather feedback on" — no one likes criticizing another person's work to their face.

• Test the system, not the user. It's important to make clear to the user that you're testing the system, not the user, and that it's a flaw in the system if they get stuck — they're not failing. In fact, finding the places where they get stuck is exactly why you're doing this test! A corollary to this rule is to not let the user flounder. If the user has gone down a path where they're obviously stuck, let them try for a little bit to see if they get unstuck, but don't make them struggle needlessly. Just make a note of the confusing point and move on to the next task.

• Share the load. It's much easier if you can split the burden of running a test between two people, one responsible for taking notes, and one responsible for facilitating the test. Trying to both facilitate and take notes can be difficult or stressful. However, if your resources are limited, it is possible to run user tests with just one person being both note taker and facilitator, especially if the parts of the prototype you are testing aren't very complicated.

• Capture themes, not every action. If you are acting as the note taker for a usability test, don't worry about recording every action and utterance from the user. As you do successive user tests, themes and obvious pain points will emerge very quickly. It is often helpful, however, to use selected, direct quotes from the user in order to illustrate these pain points to other members of your team.

• Keep it short. Participating in a usability test is hard work that takes a lot of concentration (for both the participant and the facilitators). Therefore, limiting a test to no more than an hour (30 minutes is better) usually makes sense.

• Thank your participants. At the conclusion of the test, be sure each test participant understands the value of the contribution to the project. A small thank you gift (some chocolates or a small gift certificate) never goes amiss, and is often helpful in recruiting participants.

Card sorting

Card sorting is one of the best ways to figure out how to organize different pieces of information for presentation on a website or in an application. The technique is fairly simple:

1. Divide all of the information you need to present into fairly small chunks (e.g., "Where to get your Cal 1 Card", "What businesses accept the Cal 1 Card", etc.) and write each chunk on an index card along with a few words of explanation, if necessary. Numbering the back of each card can make it easier to record the results of each test. (Numbering the back avoids influencing the user by the sequence of your numbers.)

2. Provide additional cards to label the categories that these chunks of information will be sorted into. If you wish, these cards can be entirely blank, or you can provide a few predefined categories. You should always give the user a few blank cards so they can create their own categories, or even missing pieces of information, if necessary.

3. Ask the user to sort the chunks of information into the categories that make sense to them, thinking aloud as they do so. Be sure to follow the other "tips for testing" above as you observe them.

Prototype testing

Prototype testing is what most people think of as usability testing — you have users perform certain tasks with an early version of a product and observe them to see where they encounter difficulties.

To see the greatest benefit from prototype testing, you should start testing prototypes as early as possible. It's not necessary to have a fully working system or website before you do this sort of test. We will talk about three levels of prototypes that you can use to get user feedback, even before you have a working system: paper, low-fidelity, and high-fidelity.

• Paper prototype. You don't need a computer or a single line of code written to get good user feedback — you can run a very effective test with sketches of your user interface on paper. This is known as a "paper prototype". In this sort of test, you ask one member of your team (in addition to the note taker and facilitator) to act as the "computer". When the user "clicks" (points to) the screen, the "computer" then puts the sketch showing the resulting screen down in front of them. If the "computer" does not have that screen ready, he or she can either sketch it on the spot or just use a generic "sorry, that function doesn't exist" screen to guide the user away from that function.

• Low-fidelity prototype. As your design ideas become more codified, you may wish to develop a low-fidelity interactive prototype to test with. This is a prototype quickly put together with tools such as Microsoft PowerPoint (you can create buttons or links to move you between slides, simulating interactions) or Adobe Dreamweaver (you can create static web pages which display the design but are not fully interactive).

• High-fidelity prototype. As you come closer to a final design, creating high-fidelity prototypes for testing can be very helpful. This may be an early version of your application that isn't quite complete; for instance it may have some elements hard-coded which will be interactive in the future. As an example, the program may return the same results regardless of what was entered. Or, on a larger project, you may find it helpful to develop an advanced prototype in a tool such as Adobe Flash.

  As you develop higher-fidelity prototypes which include more functionality, or if you would like to evaluate the usability of an existing system, you may wish to have part of your test with each user be a "naturalistic usability test" where you ask the user to essentially determine their own tasks by asking them to just interact as they would normally when using the system. While it's still helpful to have the user thinking aloud during a naturalistic usability test, it's important that you not interrupt their thought process. If you need to ask questions, wait until the end of the task or until there is a natural pause in the task.

Notes

[1] See James Hom's The Usability Methods Toolbox.

[2] User-centered design techniques can be used to improve the design of any product or service. However, in this series of articles, we are talking specifically about applying them to the design of IT products and services such as websites, web applications, and desktop programs.

[3] Jakob Nielsen, Usability Engineering, 1993, Academic Press.

[4] From Jakob Nielsen, Ten Usability Heuristics.