Usage Centred Design - Modelling Users and their Tasks

Usage Centered Design is a user interface design methodology developed by Larry Constantine and Lucy Lockwood. It has some similarities with Cooper's about-face methodology but uses abstract models instead of concrete ones. This makes it harder to start using but, in my opinion, gives great reasoning power once its understood and used properly.

This blog post describes the first phase of Usage Centered Design - modeling users and their tasks. A later post will describe using them to design a user interface.

Why model users?

The first key insight to understand is that we're not actually designing for users. We're designing to let people do things. This raises two important questions:

1. How can we best describe the aspects of the people and how they need to interact?
2. How can we best describe the things that they have to do?

The most well known methodology for describing the people and the things they do is Cooper's about-face methodology (http://www.cooper.com). In this methodology, users are researched and then described using Personas. Personas are precise descriptions of someone who typifies an actual user - with all details about them. They're completely made up. The things they do are described using Scenarios. A Scenario is a precise description of what a Persona might actually do to achieve their goal - it contains much information about the context surrounding the interaction with a system. There are lots of real examples of both on the web:

• http://chopsticker.com/2007/06/08/download-an-example-persona-used-in-the-design-of-a-web-application/
• http://www.uiaccess.com/accessucd/scenarios_eg.html

From my perspective, the key criticism of this methodology is that it contains too much detail - and that the detail distracts from the information. This is because the methodology isn't trying to model the users - it's trying to describe them to the most precise level of detail. Usage Centered Design is different because it models only the details that are relevant to user interface design.

How can we model users?
This is really two questions.

• What relationship between a user and a system do we want to model?
• What information about that relationship do we want to capture?

In Usage Centered Design we model the role that a user plays when they are interacting with a system and we model how they will interact with the system while they are in that role. This is called a "User Role Model" and is very similar to a Use Case Model (with some additional information about the human actors involved). Constantine and Lockwood define a user role as a set of characteristic needs, expectations, and behaviors that a user can take on when interacting with a system - users play different roles at different times to achieve different goals.

For example, in a Pizza company we can model the users by creating several different roles:

• Telephone Answerer
• Order Maker
• Order Deliverer
• Staff Roster Maintainer
• etc
  

The really important thing about these roles is that the roles are independent of the actual people who work there, their job titles, and the number of staff - these roles must be played in any pizza company. Having these roles (as well as relationships between the roles: order taker versus telephone order taker) lets us reason about the system in an abstract way. This can let us determine how

In addition, we keep some additional information about each role. This can include:

• The context of use (front of shop, potential interruption by customers)
• Characteristics of use (customers have a tendancy to change their mind)
• Criteria (speed, simplicity, accuracy)
  

In contrast, Cooper's methodology models stereotypical users and captures all information about those users.

How can we model the things that users do?
Essential Use Cases are used in Usage Centered design to model the things that users do. Each use case describes a particular task a user has to do with the system (or a goal they want to achieve with the system).

Essential Use Cases are just like ordinary use cases except:

• When writing them we have an unholy focus on the minimal, essential interaction that is necessary for the user to achieve their goal. We assume that this use case is all that the user will be using the system for - resolving the navigation between different use cases is done later.
  
• They're written in a 2-column format in order to visualize the necessary interaction.
• We write the use case from the user's perspective - the interactions that they want to have first are first in the use case. If they don't care about order then we only have 1 step.
  

This focus on the minimal interaction is key. It lets us determine how good our solution is with respect to any one use case - we can count the number of steps in the solution  and compare with any particular use case. It also lets us compare the visual layout of a solution with the order required in the use case.

In contrast, Cooper's methodology models how a particular user might actually achieve a particular goal - with all the contextual information in there.

Aren't these typical Business Analysis artifacts?
Yes, the models used in Usage Centered Design are models that Business Analysts use on a daily basis. The difference is in how the models are used. In Usage Centered Design, the analyst has to have a constant focus on the user and how they're likely to use the system. This might involve a serious amount of user research if the tasks and how they're achieved is ambiguous (or, in a Pizza company, it might not :).

I've found that it's pretty easy to explain the focus of a use case and a user role map to business stakeholders. I've also found that once they've "got it" the type of information I'm getting from them changes - we start talking about requirements instead of solutions!

That's all good, but how do we use them?
 Stay tuned for the next update: Usage Centered Design - using the models.