Usage-Centered Design

Next week, I’ll be TAing a class on Usage-Centered Design. Usage-Centered Design is a methodology that provides a framework made of easy to understand and flexible models for interface and interaction design. I understand it as a subset of User-Centered Design that emphasizes on software engineering methodologies such as use of abstract models to define concrete problems and use of an UML-inspired notification for collaborative work (among designers/developers/users). The formal process and systemic design mixes with iterative and validation parts that introduce fast prototyping techniques at an early development stage. Therefore Usage-Centered Design relies and emphasizes on thoughtful design to prevent the shortcoming usability testing and users studies. The goal is not to confuse what users with what they truly need.

In the context of the lab, abstract modeling of systems is a key skill to practice. Indeed, it is important to learn to:

• to represent the basic ideas founding a system;
• to get a global vision that allows then to zoom in on specific details;
• to keep the “doors open” to innovations and multiple design/development alternatives

Usage-centered design models ask students to compile and generate ideas (brainstorm), organize them (simplify and generalize) and focus on the necessary details (elaboration on key points). They should also learn to link clues collected from the analysis in Lab 2 (Questionnaire) and 3 (Contextual design) feed the Usage-centered design models.

Simplified global picture of the labs

Usage-centered design is driven by 3 closely related abstract models. The role model captures the characteristics of the roles that users play in relation to a system. The task model represents the structure of the work users need to accomplish in relation with a system. The content model represents the contents and organization of the user interface needed to support the identified tasks.

Process of the Usage-Centered Design methodology

User roles model
From lab 2 and 3 students collected clues on the basic users needs to use the system (who are the users, what do they do, what do they want to do, …) and detected potential design problems (what does not work well, what is not effective, …). Based on that they can deduce roles played by the users. A role is an abstract collection of needs, interest, expectations, behaviors and responsibilities that represent a relation between a type of user and the system (more a less similar to Actors in UML use cases). This relation is what the user roles model tends to capture. Each role should be informally described and can be structured in terms of profiles (competence, proficiency, type of interaction, usability criteria). a User Roles Map is used to represent the relations (affinity, specialization, composition) between the roles.

Example of a very simple user roles model

Task model (Use cases)
Uses cases are used to understand and model the nature of the work supported by each role. They help define what the users intend to do in their work using the system and what is needed to support it. A use case is a narrative description of what the system offers (black-box view) to the users as well as the interactions between the users (roles) and the system. The narration is divided in 2 parts, the user action model and the system response model.

The tasks emerge from the roles defined in the User Role Model. They can be identified by asking what what do each role need to accomplish, what do they need to know to be capable of doing it and how it can be supported by the system. It can also be what information the user examines, changes or create, how can the system inform and how do they need to inform the system.

In this lab, we will only focus on the essential use cases, that is structured narratives with generalized and abstract (no technological constraints, no complete interaction) descriptions. The structured narratives consists in three elements: a sentence describing the global intention and then the user intentions linked to the system responsibilities.

Example of the structure narrative of an essential use case

However, use cases are interrelated among each others. A Use Case Map provides a global structure of the work supported by the system and the user interface. The relations can be of type: specialization, extension, composition and affinity.

Example of a specialization relationship among use cases in the Use Case Map

Content model
A good interface architecture implies to specify the tools, material and space, therefore distribute the content of the user interface among different space and interconnect them. The content model provides an abstract representation of the content of the different interaction contexts of the system and the relation between them. The content of each interaction space represent the tools and material needed to complete the previously defined use cases. In other words, it is a derivation fo the task model. A navigation map is used to design the changes of interaction contexts imposed to the role to achieve their defined tasks.

In this lab, we plan to stick to low-tech, high-fidelity prototyping. An advantage of this approach is to prevent student to preoccupy about the visual appearance and the behaviors of the interface. They also might learn to keep “doors open” to alternative paths (or roll-backs) that could potentially prevent low-fidelity prototyping carrying “pre-concieved” ideas. The way to build a content model is:

1. For each use case narrative define the tools and material the interaction space needs to offer
2. Define the data and content needed and describe them on a Post-it
3. For the identified data extract the required function and operation. For each tool, describe its function that it used for on the Post-it

Example of a content model for a specific interaction context

Simplified example of a navigation map