PDF of this tutorialMany techniques have been employed in usability engineering, and user involvement can range from simple consultation to participatory design in which end users become part of the design team. As this tutorial is aimed at newcomers to usability engineering, only the core activities of a usability engineering lifecycle will be described. The sources listed in Topic 9, "Where to Find Out More," contain more detail.
The basic usability engineering lifecycle contains four phases, as shown in Figure 3. An initial intensive requirements gathering phase is followed by a series of rapid iterations between prototyping and user testing before final implementation. Field implementation then becomes a source of requirements for future products, and the cycle repeats.
Figure 3. Usability Engineering Lifestyle
Requirements Gathering
There are three primary activities in the requirements capture phase: user observation, interviewing, and task analysis, often carried out in that order. Other techniques, such as focus groups, questionnaires, and surveys, may be employed. Additional information on potential product features may be obtained from user groups, from sales and marketing forces, from maintenance engineers and help lines, and from analysis of competitors' products.
A stakeholder analysis should first be carried out to ascertain which parties' requirements should have a bearing on the design. Other stakeholders then must be involved in the design process. Stakeholder analysis can radically change design acceptance criteria. For example, with increasingly powerful and reliable telecommunications technology, maintenance costs are becoming a more significant cost factor. A new feature's value may need to be traded off against its potential to demand increased maintenance.
User observation will be the designer's primary source for a model of the users' domain, main tasks, and priorities. Observation is especially helpful in studying work habits of which the users themselves may not have been aware such as work-arounds, failures, and exceptions. When looking for innovation, these breakdowns can be a rich source of new product ideas. Observation gives the designers access to informal work practices—for example, observing the decisions made and the work conducted in the corridors, rather than by the formal corporate process. Observation will also bring to light the work context around the use of a particular product or application and the relationship of the use of the product to other products. Interviews with users about their work will typically be semistructured and focused around the designer's agenda but will allow the focus of the investigation to change.
There are many different task analysis techniques, usually involving a more formal and detailed interaction with users. The designers may ask users to carry out tasks while describing what they are doing and why, or the designer may even run through some user tasks, with users commenting and guiding. Video records of such sessions are often kept, so that the designers can refer back to them. One successful task analysis technique involves asking pairs of users to carry out a task, forcing the users to communicate with each other to complete the task. Formal task documentation, such as existing training material or company process descriptions, will be valuable at this stage, but the designer must still take into account the informal activities of users.
The results of task analysis typically describe the following:
- roles and related tasks
- sequences of events and relationships between them
- objects involved in tasks and their attributes, including flow of information via paper and electronic documents, etc.
- users' actions and resulting behavior
- breakdowns and problems
- users' terminology
This phase can produce large amounts of information, making it easy to lose sight of the main user priorities. One of the best techniques for ensuring continued focus on key user requirements is to capture main priorities in "scenarios." Scenarios are vignettes or stories, often produced as storyboards or short videos, which are taken from the task analysis and observation. They characterize the target user population (the stereotypes mentioned earlier), distill the key user tasks, incorporate critical design qualities, and communicate main product features.
Rapid Prototyping
Requirements capture obviously demands users' involvement. However, the design activities that follow requirements capture have traditionally failed to continue this user focus. Iterative development, by employing prototypes, is the key to ensuring that users remain at the center of the process while the product is being refined and cost trade-offs are being made. Users also often find it difficult to understand written specifications and prefer to critique rough prototypes.
Early and Late Prototypes
There are two kinds of prototypes, each with a different purpose. Early prototypes are used to validate the designers' understanding of the users' domain and to explore design alternatives. These prototypes should be partial, cheap to produce, and discarded frequently. Later prototypes are evolutionary and are gradually refined to become the finished product.
Early prototypes should be lo-fi, such as paper-and-pencil prototypes of user interfaces or inexpensive mock-ups of hardware. These lo-fi prototypes are important because they allow users to be involved early in the process and because users will feel better able to critique artifacts that are obviously unfinished. Producing high-quality prototypes at this stage is inappropriate and can divert effort from the main design issues onto small details.
When the main design issues are relatively stable, or when a predefined project deadline has been reached, a prototype will be produced that is to be refined into the final product. This prototype will need to be robust, reliable, and meet software design quality requirements. Users still must test and critique this prototype, as there will still be design trade-offs and probably some HMI compromises to be made that will affect end users.
With this understanding, software tools such as Visual Basic, Supercard, or Macromedia Director may be used for prototyping. The World Wide Web is a useful prototyping medium, as hypertext markup language (HTML) and JavaScript are easily changed and immediately accessible from a range of platforms.
Horizontal and Vertical Prototypes
Prototypes also come in horizontal and vertical varieties. Horizontal prototypes are broad but shallow, showing the range of facilities or features available without implementing any of them in depth. Vertical prototypes implement features in depth without necessarily illustrating all of those available. Most prototypes should be a hybrid, showing a broad range of intended features and implementing the key ones in depth.
Prototyping the Whole Product
If some moments of truth—important stakeholder interactions which are critical to the success of the product—have been identified, then it is quite appropriate to prototype these interactions as closely as possible, even if these are not directly concerned with the HMI. These situations should already have made their appearance in the scenarios used to focus design priorities.
For example, for a product sold mainly through retail outlets, observing buying behavior with a mock-up of the new product packaging on a shelf alongside competitive products will more accurately reflect potential buying behavior than questioning buyers about their likely behavior. Similarly, installation can be a moment of truth, as it brings together all the elements of the product in an important interaction that can set the tone for the customer's future perception of the product and manufacturer/supplier.
The user manuals, helplines, and other support also make up a vital part of the whole product. The user guide should be prototyped and tested in parallel with the product, not written as an add-on to try to cure usability problems. Similarly, the user guide need not be idiot-proofed but should adopt diverse strategies to installing and learning a new product.
