Overview > Roadmaps > Usability Engineering

Roadmap: Usability Engineering

Topics
Concepts:

IntroductionTo top of page

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

RolesTo top of page

The RUP has a number of roles responsible for usability concerns. The Business-Process Analyst, 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 and business modeling artifacts. This material is reviewed by the Requirements Reviewer and Business Model Reviewer respectively. 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.

DisciplinesTo top of page

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

RequirementsTo top of page

From a usability perspective, the Requirements discipline focusses 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:

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 end 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:
 

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 Concepts: 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 Concepts: 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.

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

Activity

Artifact

Usability Related Content

Model the User-Interface
Boundary Class,
Use-Case Storyboard

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. The Use Case Storyboard is a Use Case Realization - similar to Use Case Analysis it gives detailed guidance on how to derive the Boundary Classes that make up the user interface, and allows them to be evaluated by walking through scenarios (described in Use Case Storyboards).
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 modeling the user interface:

    • Navigation Maps [CON99] give an overview of the navigational pathways between interaction spaces (screens, windows, and dialogue boxes).
    • Card Sorting [CON99], described previously, is also useful for modeling the user interface. Each menu item or content item is represented by a card, and then the users organize the cards into logical groupings.

Business Modeling To top of page

The Business Modeling Discipline involves understanding the business environment in which the users operate.

Activity

Business Modeling Artifacts

Usability Related Content

Set and Adjust Goals Business Vision

Part of creating the Business Vision is identifying stakeholders. This includes the people that interact with the business (customers and vendors), as well as those who work in the business - many of which are or become users of automated systems.

Similar to the Vision document in Requirements, the Business Vision Template captures a description of the business's working environment and stakeholder characteristics, including their expertise, technical background, responsibilities, success criteria, deliverables etc.
Find Business Actors and Use Cases,
Structure the Business Use-Case Model		 Business Use Case Model The Business Use Case model describes the tasks (business use cases) that human Business Actors perform. It capture similarities and relationships between Business Actors, using generalization relationships. The business use cases are structured and related to one another through generalization, extension, and association relationships.
 

Business Actor

Human Business Actors are customers and/or vendors which interact with the business. These often are, or become, users of automated systems, and even when they do not correspond to users, an understanding of their characteristics provides a better understanding of the user environment. The Business Actor artifact includes the following attributes:

  • 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

See Guidelines: Business Actor.
 

Business Use Case

 The tasks performed by Business Actors are described by the Business Use Cases. These are typically free of technology assumptions and are goal-focussed - thus they qualify as "essential" (see Concepts: User-Centered Design).
Find Business Workers and Entities
 Business Object Model (Domain Model)

Business modeling is often used in a limited scope, referred to as Domain Modeling. A domain model captures the objects which are important in the domain, and therefore of interest and importance to users.

See Business Object Modeling Workshop, Concepts: Scope of Business Modeling, and Workflow Detail: Develop a Domain Model.
Find Business Workers and Entities,
Detail a Business Worker
 Business Object Model (Business Worker)

The roles filled by people in the business are described by Business Workers. Attributes similar to those described above for Business Actor are captured.

Since Business Workers are modeled as UML classes, generalization and association can be used to describe relationships between Business Workers.

See Guidelines:Generalization in the Business Object Model and Guidelines: Association in the Business Object Model. The relationships between Actors, Business Actors and Business Workers is further discussed in Guideline: Going from Business Models to Systems.
Other Other Most of the other artifacts, including Business Glossary, Business Rules, and so on, contribute to an understanding of the business, and therefore the user's environment.

Analysis and DesignTo top of page

User interface design is largely covered by the Requirements activities described previously. However, the following Analysis and Design activities are complementary.

Activity

Artifact

Usability Related Content

Use-Case Analysis Analysis Class,
Boundary Class,
Use-Case Realization

Also see the following:
Class Design
 Boundary Class

This activity uses the results of the modeling 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:
Guidelines: Boundary Class

Guidelines: Building Web Applications with the UML

Guidelines: Designing Classes in Visual Basic®

ImplementationTo top of page

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 (see Guidelines: Designing Classes in Visual Basic).

TestTo top of page

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 specification.

DeploymentTo top of page

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

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

Project ManagementTo top of page

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 Activity: 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.

EnvironmentTo top of page

The Environment discipline includes the definition of development process to be followed by a project or an organization. The Activity: 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 Activity: Develop User-Interface Guidelines which creates the Artifact: 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 PhasesTo top of page

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 (Activity: 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.

InceptionTo top of page

Two key objectives of Inception Phase are:

  • 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 Requirements and Business Modeling activities related to:

  • 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.

ElaborationTo top of page

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, re-use considerations, selection of mechanisms and patterns, etc.

This phase emphasizes the user interface modeling and design related Requirements 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 specification.

Construction To top of page

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. 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 To top of page

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 end-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.

Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process