Updated in 2003, this cross-referenced Q&A inventory is a place to get specific answers or to begin learning about usage-centered design. As a next step, try following the suggestions for learning more about usage-centered design.

Topics (Click on one of interest, or scroll through the entire page.)

Basics

1. Usage-centered design and user-centered design.
2. Application and practice of usage-centered design.
3. Essential models and model-driven user interface design.
4. Task cases, use cases, and scenarios.
5. Users, roles, actors, and personas.
6. Abstract prototypes, content models, and navigation maps.
7. Usability testing and inspections.

More Advanced Questions

8. Task cases, use cases, and UML/UP.
9. Relationships among use cases and user roles.
10. Web-based applications and Web sites for use.
11. Embedded systems applications.
12. Aesthetics, capability, content, and usability.
13. Learning more about usage-centered design.
     

 What is usage-centered design?

Usage-centered design is a systematic, model-driven approach to improving product usability. A few simple but powerful models--of user roles, tasks, and interface content--guide the user interface design toward a better fit with the real needs of users. Often, the result is also smaller, simpler systems that nevertheless fulfill all the genuine functional requirements.

 What's the difference between usage-centered design and user-centered design?

In usage-centered design the focus is on usage--on the work users are doing and the tasks they are trying to accomplish. Users, rather than being the center of attention, are involved in limited and highly focused ways to help designers build tools that will better support the work being done.

For more on the distinctions, see the paper on Usage-Centered Engineering for Web Applications.

 For what applications and problems is usage-centered design effective?

Usage-centered design has been used with marked success on a wide variety of projects in software, hardware, and Web-based applications, including such areas as: payroll, finance, insurance, and banking applications; e-commerce, distance education, and classroom instruction on the Internet; geographical information systems, visual development tools, and programming systems; medical instrumentation, consumer electronics products, and industrial automation. Any design problem in which there is significant interaction between human users and the system is an appropriate application for the approach.

See also Web applications and embedded system applications.

 Can usage-centered design be used with our development process and methodology?

Usage-centered design, a "front-end" process focused on user requirements and user interface design, can be incorporated into virtually any modern software design and development process or method, or it can be used as a guiding design approach in itself. Various parts of the usage-centered design process are separable and can be applied independently. Because it is based on use cases, which are employed in most modern development methods, usage-centered design can provide a thread linking user requirements and the design of user interfaces to the internal software and information architecture.

See also UML/UP.

 Have Extreme Programming and other "agile" processes eliminated "big design up front" (BDUF)?

Up-front design does not have to become a form of analysis paralysis. User role models and task models can be developed very quickly using ordinary index cards. Paper prototypes to inspect with users and to guide programmers are also easily developed from simple task models. In order to avoid major usability blunders and big problems downstream, a minimum of up-front analysis and design are required. We find that a navigation architecture and a user interface design scheme or "abstract style guide" are absolutely essential. Usage-centered design has proved to be a streamlined process that can be made as agile or lightweight as necessary.

For more details, see papers on Process Agility and Usage-Centered Engineering for Web Applications.

 What is an essential model?

An essential model is technology and implementation-independent. By eliminating all unnecessary assumptions or restrictions based on how a system will be implemented, essential models get closer to the heart of the underlying problems being solved. Essential models are abstract, simplified, and generalized in comparison to concrete or physical models that represent designs literally. For a classic treatment of essential modeling, see McMenamin and Palmer, Essential Systems Analysis.

 Why use essential models for user interface design?

Essential models make it easier to work out the "what" before becoming lost in the details of the "how." Core requirements, user needs, and the content and organization of user interfaces can be determined without becoming caught up in look-and-feel issues or the choice of GUI widgets. Essential models also encourage creative innovation by keeping designers from becoming trapped in their own unstated assumptions.

 Doesn't modeling slow down design and development?

Effective models actually save time in design and development. Models help developers quickly understand their users and the tasks to be supported. Alternative designs and major revisions to architecture can be explored more rapidly through simple models. The models employed in usage-centered design are simple and easy to develop. Remember, all the time spent designing and building the wrong system is time completely wasted.

 Task cases, use cases, and scenarios--what are the differences?

All use cases are just cases of use, something meaningful to do with a system from the point of view of an external user. Task cases are use cases written in essential form, that is, abstract, simplified, and technology-free. Conventional use cases describe the actual interaction between a user and a system in terms of user actions and system responses taking place through a particular user interface. Task cases (or essential use cases as they are sometimes called) are abstract and based on the purposes of interaction. They describe user intentions and system responsibilities.

A conventional or "concrete" use case to reset a thermostat might look like this:

An essential form of the same use case might look like the one below. Note how the dialogue has been simplified by focusing on the purposes of interaction and eliminating assumptions about the user interface.

When used as a guide to design, such task cases can inspire simpler user interfaces that require fewer steps. This example, for instance, might lead to "up/down" buttons that operate directly on the temperature setting.

Scenarios are related to use cases, and some people even prefer to call use cases scenarios, but a scenario is really a plausible vignette or story, a composite thread incorporating particular instances or enactments of one or more use cases. For example, creating a letter of reference for a colleague might be a scenario composed of a number of use cases for a word processor.

 Why are task cases structured in columns?

In usage-centered design, we try to organize information for easy interpretation. Separating user intentions from system responsibilities highlights the system boundary--the user interface--and separates external from internal requirements. This useful little innovation originated with OO guru Rebecca Wirfs-Brock. Too bad the UML folks haven't adopted it.

See also UML/UP.

 What is a user role?

A user role is a particular kind of relationship between some users and a system. In other words, roles are played by users. A role is an abstraction, a collection of characteristic needs, interests, expectations, and behaviors. Any one user may play many different roles, even in relation to the same system, and, of course, any number of users may play the same role. The user of a presentation package might at one time be in the Routine-Show-Creating Role and another time play in the Sophisticated-Slide-Editing Role or the Web-Presentation-Publishing Role.

 What is the difference between actors and user roles?

The term "actor" is used in object-oriented software engineering, the Unified Process, and in UML. An actor can be any external user, including other systems; in usage-centered design, our interest is in just the human users. In UML and the UP, an actor is defined as a role played by a user, but this verbal legerdemain can lead to confusion. Just as it is important not to confuse screen actors with the characters they sometimes play, so it is vital in user interface design to distinguish the roles in relation to a system from the actual people who may play them. To avoid confusion with UML terminology, we call the actual person who plays a particular user role the "role occupant." We use the term "system actor" to refer to the non-human actors interacting with a system.

See also UML/UP.

 How are "personas" different from user roles?

Personas are a variation on user roles popularized by Alan Cooper. Rather than abstracting the essential features of a relationship, personas are described as if they were real, specific persons, with personality, detailed history, and complete background. Although constructing the character of a persona can be a fun exercise, the concrete detail can obscure features of the underlying role that are essential for good design. Descriptions of actual users or representative personas can be a starting point for role modeling, but good design is best served by first describing roles in the abstract. Selected roles can then be "fleshed out" as personas if this is desired.

See also the newsletter item on personas.

 What use is a user role map?

User roles may be interrelated in several different ways, and the user role map just maps out the relationships among use roles. Roles may be similar in an unspecified way (affinity), one role may be a specialization of another more general role, one role may be composed of other roles, and roles may otherwise depend on each other. For example, it is sometimes useful to represent that one role must be occupied (played) before another one can be; the Draft-Writing Role necessarily precedes the Final-Editing Role, for instance. The user role map is a simple diagram showing all the user roles and their interrelationships. It is an effective tool for getting an overview of all the variety of users to be supported.

 What is an abstract prototype?

Abstract prototypes enable developers to design the overall organization and architecture of software and web-based applications without drawing components or detailing layout. Abstract prototypes consist of an interface content model describing the contents of the various contexts within which user interact with the system plus a context navigation map showing how users move from one context to another in the course of enacting use cases.

See the paper on abstract prototyping.

 Just what is a content model?

A content model shows the intended contents of part of a user interface. It consists of abstract tools and materials assembled into particular interaction contexts. Abstract tools represent commands, operations, operators, or other active components that cause an action of some sort. Abstract materials consist of the data, information, containers or objects that are operated upon or affected by tools. Each interaction context becomes a page, screen, dialogue, or other part of the actual user interface. Abstract tools and materials become the various user interface controls and widgets.

 Why not just draw or build a real prototype?

Abstract prototypes have several advantages. First, they provide an overall picture of the complete architecture of the user interface. Second, the abstract nature of the content and navigation models allows detailed decisions to be deferred. Abstraction encourages creativity in design, and experience has shown that more innovative interface designs result when an abstract prototype is used as a guide to the final visual and interaction design.

 What is an implementation model?

Implementation model is a fancy term for the paper prototype and accompanying descriptions that specify the visual and interaction design for a user interface. An implementation model defines not only the appearance, but also the behavior of the planned user interface. Ideally, the implementation model is derived from an abstract prototype which specifies the overall architecture of the user interface or web site.

 What is a canonical prototype?

A canonical prototype is an abstract prototype constructed from a standardized set of abstract components. Canonical abstract components model function, size, and position within interaction contexts, but not appearance or detailed behavior. The canonical set covers the full range of abstract user interface functions, such as holding information, accepting user input, or starting a process. With the size and position of canonical components represented in the abstract prototype, canonical prototypes are intermediate between simple content models and realistic or representational paper prototypes.

For more information, see the paper on canonical prototypes.

 What about usability testing?

Usability testing is a useful means for finding residual or lurking usability defects in working systems or functional prototypes. However, usability testing, the genuine article, comes late in the development process at a time when needed changes can be expensive or difficult. Testing is particularly inefficient for improving systems which are riddled with numerous problems or whose fundamental assumptions and organization are wrong. Usability testing is most effective for finding the residue of hidden, obscure, or overlooked problems in otherwise well-designed systems. In usage-centered design, the objective is to get the design almost right in the first place, then do limited and focused testing to identify the few remaining problems missed in the design process.

 Can paper prototypes be tested with users?

Just as in programming, you can do a review or walkthrough of a design, but only running code can be tested. If you sit users down with a paper prototype or other static or non-functional design artifact and ask them to "try it out," you are conducting a review or walkthrough, which can be useful but should never be confused with genuine testing.

 What are collaborative usability inspections?

Collaborative usability inspections are systematic, structured reviews of a design, prototype, or working system for the purpose of identifying and classifying usability defects. Designers, developers, and users follow a set protocol with strict rules that maximize the efficiency of the process. Experienced inspection teams can find 100 or more defects per hour.

 Are focus groups useful for evaluating designs?

Focus groups can be effective tools in product planning, sales and marketing strategy, and for testing the waters in terms of customer responses, but they are ineffective and even misleading for evaluating usability. In one case, a Web site that had been refined through input from numerous focus groups and which had been well-received in demonstrations, proved almost completely unusable in practice.

 Are task cases (essential use cases) different from use cases in UML?

Like most object-oriented notations and methods the Unified Modeling Language (UML) developed by Grady Booch, Ivar Jacobson, and Jim Rumbaugh and now an OMG standard includes use cases. However, it does not formally or explicitly recognize essential use cases. Indeed, the UML does not define or specify the narrative form that defines the contents of use cases. Typically, use cases based on UML are expressed as concrete interactions written in a simple narrative form as a list of steps. As such, they are less effective tools for user interface design and for improving product usability.

See also use case relationships; see also actors and user roles.

For more detail, see the paper on structure and style in use cases.

 Do essential use cases and usage-centered design fit with UML and the so-called Unified Process?

Essential use case modeling and the techniques of usage-centered design can be incorporated into almost any software development life cycle model--or even no method at all. Although there are minor differences in notation, for the most part, simply conforming to the UML conventions is acceptable. The important exception is that we strongly recommend the superior form of structured narrative used in usage-centered design to detail use cases.

See also usage-centered design process.

 What is an affinity relationship?

Often, you may know that two roles or two task cases have something in common or are similar in some way but not know precisely what relationship they have. A vague or unspecified similarity is called an affinity. In the interest of quickly getting insight into the overall structure of a problem, we often start out by doing an affinity clustering. Putting the task cases (or user roles) on index cards or Post-it notes simplifies sorting them into groups or loose collections of similar or related examples. Specifics can be worked out later, but at least this way we know how things go together.

 Why complicate task models with specialization, composition, and extension?

Separating out the meaningful common and reusable parts of task cases ultimately simplifies the model overall. Specialization recognizes that some task cases are just specialized variants of other, more generic ones. Just as with inheritance in object-oriented design, we do not have to keep rewriting the generic parts every time we describe a specialized variation. Similarly, composition allows us to construct complicated task cases by having them use other task cases. Extension allows us to keep the base cases that represent the primary or normal course of events clean and simple by separating out the unusual or exceptional interactions.

 What is the difference between extension and inclusion?

The distinction is is a tough one that throws many people. In many situations, it may not be completely clear which relationship is needed or appropriate. An extension task case describes an optional, alternative, or exceptional case that may or may not be enacted in the course of enacting the task case that it extends. The extension case refers to or points to any task cases it might extend. In this way, once an error handling procedure has been recognized as an extension task case, it can extend any number of other task cases. By contrast, one task case is said to use or include another when it requires the sub-case as a sort of subroutine, such as logging into server as a required sub-part of publishing a Web. Both extension and composition allow us to simplify the narrative body of the base case by separating out some of the detail and placing it in other task cases that can be shared or reused.

 What is a task case map?

A task case map simply maps out the relationships among task cases. It's a simple diagram showing all the task cases and their interrelationships. It is an effective tool for getting an overview of all the tasks to be supported. In addition, the use case map and the relationships it models guide the designer in deciding what things to put together on the user interface and what things to separate.

 Is a task case map different from the UML/UP "use case model"?

A use case model as used in the UML/UP is a diagram of the relationships among use cases and between use cases and actors. For real-world problems of any substantial scope, which may have dozens of actors and hundreds of use cases, the diagram becomes too visually cluttered to be readable or of much use except as documentation.

 What is a Role-Support Matrix?

For large or complex projects, we find a matrix or tabular form is a more useful way to display the relationships between task cases and user roles. Each row is a task case and each column is a user role. The cell at the intersection identifies whether a task case supports (is used by) a particular role. A more elaborate form can specify whether a given task cases is necessary, desirable, irrelevant for a particular role.

See the newsletter item on requirements and role-support.

 Can usage-centered design be applied to Web sites and Web-based applications?

Web sites are applications and Web pages are user interfaces between users and the site, but usage-centered design for the Web requires some special considerations. We and our clients have found the basic models--roles, tasks, and content--are extremely useful for Web design, but the accelerated time-frame of Web development may call for compromises and for streamlined processes. Web development is complicated by constraints in the choice of interface widgets, control over layout, browser compatibility, connection speed, and other technical issues.

For more details, see Usage-Centered Engineering for Web Applications.

Are the issues in essential modeling the same for the Web?

Compared to desktop applications, which tend to have relatively specific and constrained purposes, Web sites often can suffer from a certain lack of focus in both mission and target audience. It really pays to start by clarifying and prioritizing site purposes, both in terms of business objectives and in terms of the needs of targeted users. Establishing clear priorities in terms of user roles and tasks to be supported is particularly vital.

Are Web users different?

From a design standpoint it is especially important to understand how readily Web site visitors can shift among roles. The transitions from one role to another need to be considered and managed if possible. The fact that the user can so easily and quickly abandon a site to go to the competition or another resource needs to be taken into account. It can be of great importance if and when a Frustrated-Product-Installer switches roles to become an Interested-Add-On-Buyer or a Disgruntled-Email-Help-Seeker.

See also user roles and aesthetics.

 What about embedded systems applications?

Essential use cases and usage-centered design have been applied to problems ranging from medical technology to consumer electronics and industrial automation equipment. Designers must look at the whole system, not just the embedded code or the button panel or the LCD display. Every aspect of the design, right down to the printing on the equipment case, can have an impact on usability.

Are task cases useful for embedded systems applications?

Designing based on task cases can dramatically simplify product usage. Particularly in embedded systems applications, designers can get caught up in naive "simplifying" to the point of stupidity. Despite supposedly "user-friendly" on-screen menus, many consumers still find programming their VCRs a tedious, frustrating, and error-prone experience. Why? Because the designers never thought through the task cases. Reducing the number of buttons on a keypad or making all operation menu-driven does not necessarily simplify use. Users can still be left stupefied by mind-boggling trips through mazes of menus. The central issue is how many steps it takes to enact focal use cases, not whether the graphic design of the control panel is elegant.

 Isn't aesthetic appeal the real issue, especially on the Web?

Many designers see aesthetics and pragmatics as fundamentally at odds. Aesthetic appeal and the artistic quality of graphic design are important aspects of product design, but when aesthetics drive the design process, usability often suffers. In our experience, the secret of having your cake and eating it too when it comes to usability and aesthetics is to put graphic design and artistry in service of usability. Design for usability, then refine for aesthetic appeal.

See also the newsletter item on aesthetics and usability.

 What about user satisfaction and the quality of the "user experience"?

User satisfaction is a fundamental factor in overall usability--along with ease of learning, retention, efficiency, and reliability. Unhappy, dissatisfied users make more mistakes and work more slowly. But the most important aspect of satisfaction is goal satisfaction. If you can't get the information you are after or purchase the product or accomplish any other task of interest, it doesn't matter how good the graphics are or how harmonious the color scheme might be. The content and capability must be present and they must be accessible and usable to make a satisfying user experience.

 Are there tradeoffs among aesthetics, content, and usability?

Content, aesthetics, and usability are independent aspects of the purpose profile that defines and characterizes the business objectives of an application, especially on the Web. It is possible for all three to be considered equally important, but more often than not one or two will dominate the agenda. You can achieve all three--high usability, good content, and fine aesthetics--but you must address them in that order, and, of course, it will cost you more, at least in terms of thought and attention.

See also Web applications, see the newsletter item on aesthetics and usability

 How can I learn more about usage-centered design?

We offer public seminars in usage-centered design as well as in-house training programs custom-tailored to your needs. We also organize forUSE, an annual international conference on usage centered design; the proceedings of forUSE 2002 are available. The comprehensive original written resource is our book, Software for Use. You'll find an array of materials on this Web site, including articles and newsletter archives. For a broad overview, two good starting points are "Usage-Centered Engineering for Web Applications" and the classic "What do Users Want?"