100 User Experience (UX) Design and Evaluation Methods for Your Toolkit
This is the 18th in a series of 100 short articles about UX design and evaluation methods. I’m back from my sabbatical and ready to keep building the UX methods toolbox. Today, we’ll look at a simple task analysis method called the User/Task Matrix.
Method 18 of 100
Understanding the frequency and importance of tasks that are performed by different classes of users (or personas) is critical for many design decisions. For example, if an architect will be using a function hundreds of times a day for weeks on end, then you would want to design a highly efficient user interface that included shortcuts and ways to select many things at a time. In contrast, you might have some features, like creating templates, that you do occasionally and designing the UI for templates might require support for fast learning and “re-learning” after gaps of use. If you are designing something that you only do once a year and that task is critical, you might design a step-by-step procedure. A simple approach for exposing frequency and importance by user class is the user/task matrix. This approach can also indicate which tasks are primarily the responsibility of a single user group and which ones cross groups.
Here is a generic example of a user/task matrix. The letters represent task frequency: H = high; M= medium, and L = Low. Task 4 in the matrix is a critical task and is marked with a red background. Only one user group performs that critical task with low frequency so the interface related to that task should focus on preventing errors and be easy to learn.
User Groups |
User Group 1 |
User Group 2 |
User Group 3 |
User Group 4 |
User Group 5 |
User Group 6 |
Task 1 |
H |
H |
M |
M |
M |
M |
Task 2 |
L |
|
L |
M |
H |
M |
Task 3 |
L |
L |
L |
L |
M |
|
Task 4 |
|
L |
|
|
|
|
Task 5 |
L |
L |
|
|
|
L |
When to Use:
You can use a user/task matrix to:
- Summarize data related to frequency and importance of tasks.
- Determine whether some tasks are used by a few types of users or many users. In the example matrix, tasks 1, 2, and 3 are used by almost all groups with varying frequencies. This information can be helpful for making trade-offs about what features should get priority during the design and development cycle. For example, something that is important, done by many user groups, with moderate to high frequency, might be an area to focus usability sessions.
- Consider whether the primary focus for design should be on ease of learning or ease of use (efficiency).
- Determine if different classes of users can be combined into a single class.
- Provide some clues about where to focus user assistance development.
Procedure:
- Ask questions about task frequency and importance when conducting user research.
- Develop a set of user groups or personas that represent the major classes of users. Keep in mind that there are some low frequency tasks (like initial deployment of software across an organization) that are critical to success and often performed by a small group of users.
- Develop a visual coding scheme for highlighting frequency and importance in your matrix. My example is very simple.You can extend the basic concept in my example to create something visually compelling.
- Use the matrix as input to feature and UI design trade-offs and other design activities. A related method called the UXI matrix was presented at the 2011 UPA conference by Jon Innes and James McElroy and discussed by John Schrag at http://dux.typepad.com/dux/2011/06/the-forgotten-user.html
Strengths and Weaknesses:
+ The user/task matrix is simple and conveys critical information for design teams who are considering what aspect of usability they should focus on during conceptual design
+ You can easily substitute the language of your organization into the matrix. For example, you might substitute “stories” into the task column and “personas” into the user group row.
- If you have hundreds of tasks, the matrix can become unwieldy and you might have to create a hierarchical version.
References:
Hackos, J. T., & Redish, J. C. (1998). User and task analysis for interface design. New York, NY: Wiley.
Wixon, D. & Wilson, C. E. The Usability Engineering Framework for Product Design and Evaluation. Handbook of Human-Computer Interaction (Second Edition). Elsevier: Amsterdam, The Netherlands, 1998, pp. 653-688.
What’s Next in the Series?
In the next post, I’ll describe an interview technique called “laddering” which is used to get at root causes, understand how knowledge is organized, and get insight into organizational cultures.
Comments