Concepts:

Introduction

Usability Engineering (also called User-Centered Design) is all about building better systems by getting a better understanding of the users, and involving users in requirements, user interface design, and testing efforts. Basic concepts are described in Concept: User-Centered Design, and should be read prior to this concept. This concept page explains how the Rational Unified Process (RUP) currently addresses usability engineering techniques.

Roles

The RUP has a number of roles responsible for usability concerns. System Analyst and Requirements Specifier must be skilled in gathering and analyzing information about users, their tasks, and their environment, and capturing these in the requirements . This material is reviewed by the Requirements Reviewer. The Tester and Test Analyst roles are primarily responsible for usability testing. The User-Interface Designer is responsible for the design and the "visual shaping" of the user interface. The Implementer selects and/or develops user interface components to construct the functioning user interface.

The Project Manager also has a key role. He/she enables users to be involved in the development process, and ensures that the development organization is staffed with the skills required to build usable systems. Other roles, such as Deployment Manager, Course Developer, and Technical Writer also have responsibilities for ensuring that the deployed system is usable.

Disciplines

The following sections describe RUP disciplines in terms of the activities and artifacts which are most important to usability.

Requirements

From a usability perspective, the Requirements discipline focuses on:

establishing an understanding of the users and their needs
identifying the use cases of greatest benefit to the users.

The specific activities and artifacts are as follows.

Activity	Artifact	Usability Related Content
Elicit Stakeholder Requests	Stakeholder Requests	This activity involves interviewing users, questionnaires, and holding workshops to better understand the user and the user environment. This includes the following: Assessment Workshop Requirements Workshop Interviews Brainstorming and Idea Reduction Storyboarding Role Playing Reviewing Existing Requirements The template for Artifact: Stakeholder Requests captures a detailed user profile, including educational background, computer background, experience, existing environment, expectations, goals, etc. It also captures a description of problems and priorities from the user's perspective. Stakeholder Requests are the raw material from which the Vision is compiled.
Develop Vision	Vision	The User Environment section of the Vision template describes the working environment of the users, or what ISO refers to as the Environment Context [ISO 13407]. The User Profile section of the Vision template describes the user's expertise, technical background, responsibilities, success criteria, deliverables etc. This is what ISO refers to as the User Context [ISO 13407].
Find Actors and Use Cases, Structure the Use Case Model, Detail a Use Case	Use-Case Model	The Use Case Model describes the tasks (use cases) that users (human Actors) perform. It capture similarities and relationships between Actors, using generalization relationships. Actors are related to use cases through This is similar to Constantine's "Role Model" [CON99]. The use cases are structured and related to one another and to actors through Communicate-Association, include, generalization, and extension relationships. Workshops are an excellent way to involve the user. See: Use-Case Workshop
	Actors	The characteristics of human actors are captured as attributes of Actors. These include: The actor's scope of responsibility. The physical environment in which the actor will be using the system. The number of users represented by this actor. The frequency with which the actor will use the system. The actor's level of domain knowledge. The actor's level of general computer experience. General characteristics of the actors, such as level of expertise (education), social implications (language), and age.
	Use Cases	These can include essential use cases as described by Constantine [CON99] (see Concept: User-Centered Design for a discussion of essential use cases). Specific usability requirements for a given use case may be captured as "Special Requirements" in the use case specification.
Detail the Software Requirements	Supplementary Specifications	The Supplementary Specifications capture requirements not specified in the use cases. This includes availability and performance requirements which may be closely tied to usability. General usability requirements applicable to multiple use cases are captured here, along with applicable legislation and usability standards (see Concept: User-Centered Design for details on usability legislation and standards).
Manage Dependencies	Requirements Attributes	As use cases and usability requirements are "discovered", their importance or benefit should be noted. This requires consultation with users and other stakeholders. Other attributes, such as the frequency a use case is executed, may also be captured in this artifact.
Review Requirements	Change Request	A user-centered development effort involves users as much as possible in all requirements reviews.
Capture a Common Vocabulary	Glossary	Captures common vocabulary terms specific to the users' domain to facilitate communication and understanding between users and the rest of the development team.

There are some other techniques which may be useful additions to the above Requirements activities.

Affinity Diagramming [HOL96, BEY98] is a technique which each piece of information gathered about the users and their tasks is placed on a sticky note. The users and analysts collaborate to cluster related notes into conceptual groups or "affinities". This activity helps promote a common understanding of the issues, their relative importance, and their relationships.
Card Sorting [CON99] is a similar activity where information on index cards is organized into groups. Cards can also be sorted by importance, frequency, and so on.
Hierarchical Task Modeling [MAY99, CON99] analyzes the tasks currently performed by users and organizes them into a hierarchy. The hierarchy should reflect how users currently understand the organization of their tasks.

Analysis and Design

A number of other activities in this discipline are focused on the shaping and design of the user-interface. These are:

Activity

Artifact

Usability Related Content

Design the User-Interface

Storyboard

Navigation Map

This activity is creates what is often referred to as the Conceptual Design [FER01]. This is the initial abstraction of the user interface itself, capturing the main windows and navigation paths presented to the user. This activity focuses on use cases that drive the user interface design.

Navigation Maps, see [CON99] give an overview of the navigational pathways between interaction spaces (screens, windows, and dialog boxes).

Prototype the User-Interface

User-Interface Prototype

You can make three basic kinds of prototypes:

Drawings (on paper)
Bitmaps (drawing tool)
Executables (interactive)
In most projects, you should use all three prototypes, in the order listed above.

The main purpose of creating a user-interface prototype is to be able to expose and test both the functionality and the usability of the system before the real design and development starts. This way, you can ensure that you are building the right system, before you spend too much time and resources on development.

The following techniques may also be useful as part of designing the user interface:

Card Sorting [CON99], described previously, is also useful for designing the user interface. Each menu item or content item is represented by a card, and then the users organize the cards into logical groupings.

In addition to the activities described above, the following Analysis and Design activities are complementary to the designing of the user interface:

Activity

Artifact

Usability Related Content

Use-Case Analysis

Analysis Class,
Use-Case Realization

Also see the following:

Class Design

This activity uses the results of the designing and prototyping of the user interface and designs the classes. Unlike the prototypes, this is not throwaway conceptual user interface work, but is intended to represent the design of the delivered system.

Also see the following guidelines:

Guideline: Building Web Applications with the UML

Implementation

The implementation of the user interface follows the general Implementation Workflow. Note that implementation of the user interface is often done as part of the design activity.

Test

Usability Testing, including usability-related Performance Testing, should be started as soon as there are mockups or executable prototypes of the user interface. Testing should include verification of usability and performance requirements captured in the Supplementary Specifications or as "Special Requirements" in the Use Case.

Deployment

Users should be heavily involved in Activity: Beta Test Product, as well as final Usability Testing during Activity: Manage Acceptance Test.

Activity: Develop Support Material includes development of training material and system support material to ensure that users can successfully use the delivered software product.

Project Management

Project Management is the art of balancing competing objectives, managing risk, and overcoming constraints to successfully deliver a product which meets the needs of both customers (the payers of bills) and the users. From a usability engineering perspective, the most critical activity is Task: Define Project Organization and Staffing. This activity defines the organizational structure, external interfaces, and roles and responsibilities. This includes defining the extent to which users will be involved in the development process, and determines whether the developers should be experienced with usability engineering methods.

Environment

The Environment discipline includes the definition of development process to be followed by a project or an organization. The Task: Develop Development Case (Artifact: Development Case) defines which usability engineering techniques will be applied, and how the various RUP artifacts and activities will be tailored to incorporate these techniques.

Another important activity is Task: Develop Project-Specific Guidelines which creates the Work Product: Project Guidelines that includes user-interface guidelines. These guidelines help ensure consistency of the user-interface, which can be a significant aid to usability. They also capture usability principles to be followed, such as guidelines for shortcuts, "undo" capabilities, recognizable exits, modeless interaction, and so on.

Iterative Development and Phases

The software lifecycle of the RUP is decomposed over time into four sequential phases, each concluded by a major milestone; each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed (Task: Lifecycle Milestone Review) to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.

Within each phase may be several iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. Usability benefits greatly from this iterative approach. It allows users to provide early feedback on usability, and avoids heading too far down a path which simply won't meet user needs.

The user should be involved in each iteration, to further refine requirements, to evaluate design concepts, and test/evaluate the usability of both proof-of-concept prototypes and the evolving system.

The following sections describe the usability-related phase completion criteria and the main activities for each phase.

Inception

Two key objectives of Inception Phase are Inception :

Establishing the project's software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not.
Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design trade-offs.

From a usability engineering perspective, this means emphasizing the activities related to Requirements and Business Modeling (if performed):

establishing an understanding of the users and their needs
identifying the use cases of greatest benefit to the users.

Inception phase is also often the time to explore some conceptual design and "proof of concept" prototyping. This is particularly true when the primary project risks are related to the user interface and usability concerns. Usability Testing, including usability-related Performance Testing, should be started as soon as there are mockups or executable prototypes of the user interface.

Elaboration

As RUP is an iterative process, the artifacts created in Inception are revisited and reviewed with users in order to manage scope and ensure that the evolving system meets user needs.

In Elaboration, the focus is on the Software Architecture - including the architecture of the user interface. The conceptual user interface is defined, and the critical and/or risky elements of the user interface design are implemented. Activities related to the software architecture apply in general to the user interface - there are off-the-shelf products that must be evaluated, reuse considerations, selection of mechanisms and patterns, etc.

This phase emphasizes the user interface design activities, as well as supporting activities from the Analysis and Design discipline. Implementation and Test are also involved, since completion of Elaboration requires that a running system be constructed which can be evaluated.

Usability Testing, and usability-related Performance Testing, should focus on any risky requirements captured in the Supplementary Specifications or as "Special Requirements" in the Use Case.

Construction

In Construction, the focus is on implementing more use cases. This involves adding to the user interface, while remaining true to the conceptual model of the user interface and user-interface guidelines captured in the Project-Specific Guidelines. Usability Testing continues to be very important as new features are added.

The selection of what functionality to place in each iteration is based on value to users.

Transition

The focus in Transition phase starts to shift towards the Deployment discipline. In a user-centered development effort, you shouldn't wait until Transition phase to involve the user. However, the user continues to be involved, primarily to give feedback. When the user has been involved throughout the development, formal beta and acceptance testing is often significantly minimized or non-existent. Instead, detailed user feedback and approval occurs throughout the development effort.

Development of training material and system support material is finalized in Transition, but it should be started in earlier phases, if possible, in order to allow user feedback.

In Transition, there is a working system that can be used by users. It is a good idea to plan at least a couple of iterations during transition, so that problems with the initial release can be corrected, and so that key user feedback can be incorporated.