Previous Table of Contents Next


2.2. REQUIRED USABILITY ENGINEERING SKILL SET

The usability engineering skill set includes:

  User interface analysis, design and evaluation skills.
  People and facilitation skills, especially for Joint Application Design (JAD) and focus group sessions.
  Project management experience.
  Background in software analysis, design, programming, and testing, in order to understand how much effort a user interface change might require.
  Ability to read any data, object, or process model.
  Ability to learn to use any prototyping tool.
  Ability to become a subject matter expert very quickly.
  Ability to set aside one’s own preferred mental models, interaction styles, and software/hardware platform details.
  Courage and persistence to pursue an effective user interface design, grace to accept user interface design flaws that cannot be changed, and the wisdom to distinguish one from the other.

Not all members of the usability engineering team need to possess all of these skills, but all skills should be represented on the team.

2.3. USABILITY ENGINEERING TOOL KIT

The usability engineering tool kit to produce rough drafts contains flip charts, white boards, string, colored stickies, colored markers, colored dots, tape, scissors, and a big cookie jar. The author’s experience has been that low-cost prototyping with such a tool kit is the most effective, efficient, and cheapest prototyping method up to and including the first pass of detailed design for the development of most applications or products. Only after this stage is it worthwhile to build computer-based prototypes for polishing the user interface design. A wise choice of the computer-based prototyping tool will allow the polished prototype to be carried over into development.

2.4. USABILITY ENGINEERING ROOM

A usability engineering room is essential to aid in the construction and maintenance of subject matter knowledge and user interface design ideas. Sometimes called a “war room” (see Chapter 10 by Simpson), it is used to post flip charts with specific usability principles, designs, unresolved and resolved issues, to conduct focus group meetings and JAD sessions, and to hold free and open discussions of design alternatives. There is no specific allocation of wall space to particular types of postings; rather, the wall space is used and reused for postings as needed.

2.5. USABILITY ENGINEERING PROJECT PLAN

Understanding the overall project plan and budget allows the usability engineering project manager to position usability activities from the usability project plan within the overall project plan. It is essential to identify clearly the scope and content of each usability engineering deliverable. Provisions must be made for including design rationale in each deliverable so that there is a record of user interface design trade-offs and decisions. Each level two subsection in sections 3 and 4 below corresponds to a deliverable in the usability engineering project plan. If the project employs a traditional “waterfall” development approach, scheduling iterative user interface design work is often difficult.

3. USABILITY ANALYSIS — LAYING THE FOUNDATION OF THE BRIDGE

The bridge from user/system requirements to a reasonably polished user interface design for a complex legacy system must have a solid foundation, the results of the usability analysis phase. The following information should be available or constructed as part of the usability engineering effort, and then documented, reviewed, and approved by the Steering Committee:

  Business objectives for the application (Section 3.1).
  Definition and description of current and new user classes (Section 3.2).
  Current task definitions (Section 3.3).
  Malfunction analysis of the current system (Section 3.4).
  System requirements, functional requirements, and functional specifications (Section 3.5).
  Training and documentation strategy (Section 3.6).
  Hardware/software environment (Section 3.7).

3.1. BUSINESS OBJECTIVES FOR THE APPLICATION

Business objectives must be expressed as specific measures of success such as cutting the turnaround for loan applications down to one business day, reducing the error rate from 30% to less than 5% when filling in a form for a specific product, or reducing training for the application from 5 days to 1 day. These business objectives state the measures of success from a business perspective; they drive the usability performance objectives and the usability project plan and budget. For example, if one of the business objectives is to reduce training time required, then the usability plan and budget will allocate effort and money specifically to designing the user interface for learnability. Business objectives are often found in business case descriptions for a project, in a Request for Proposal, or in a requirements definition document.

The usability engineers must “translate” the business objectives into general usability design principles for the application. For example, to reduce the error rate, the usability principle of preventing errors (Molich and Nielsen, 1990) must be applied, specifically, by guiding the user through the steps of a task, by checking for errors immediately rather than at task completion, and by providing graceful error recovery mechanisms. The last is especially important when a customer and a user look at a screen together. These application-specific guidelines are the foundation for the later definition of usability performance objectives.

The application-specific guidelines are documented in a memorandum and posted on flip charts in the usability engineering room. The guidelines are required for both fire prevention and firefighting assignments; the difference is in the effort expended to identify them and have them approved. For fire prevention assignments they are identified by thorough analysis based on brief interviews with all stake holders. This obtains buy-in from the stake holders, and it is a good opportunity to sell usability within the organization. For firefighting assignments, principles are identified in a JAD session with the Steering Committee.


Previous Table of Contents Next