Previous Table of Contents Next


3.5. SYSTEM REQUIREMENTS, FUNCTIONAL REQUIREMENTS, AND FUNCTIONAL SPECIFICATIONS

The usability engineer must be able to read and understand the models of the business and the system/application developed by business systems analysts or systems engineers (see Sowa and Zachman, 1992). The usability engineer must also be able to read or interpret the results of whatever object-oriented software engineering tool or computer-assisted software engineering tool is employed in the project. Frequently, the user interface designer has to map these detailed models onto objects from a user’s perspective (these are usually higher level objects) and then track the mapping throughout the user interface design process.

Designing the user interface objects and actions first and then mapping them onto the system/application model would seem a more logical approach to designing the user interface. However, it carries a significant risk. Without an understanding of the system/application model, the user interface design of objects and actions may include functionality that is out of project scope (the scope is defined through the system/application model). Inadvertently exceeding project scope by designing the user interface without an understanding of the system/application model may create user expectations that cannot be satisfied, leaving the users disappointed.

It has been the author’s experience that managing user expectations is one of the key concerns of senior management and a main obstacle to securing user involvement. Demonstrating an understanding of and respect for the project scope by understanding the system/application model is an effective way of addressing these concerns. If the usability engineers base the user interface design on the system/application model that is used by all other teams on the project, the usability engineers will significantly enhance their credibility with the software developers.

There are also projects where development is fast tracked, going from high level system requirements directly to abbreviated requirements analysis/software design and coding, skipping the detailed definition of functional requirements and business processes. In such situations, the usability engineer has to take on the role of the systems analyst in order to define the functional requirements and business processes to a level of detail from which new user work flow and task design can begin.

3.6. TRAINING AND DOCUMENTATION STRATEGY

The user interface design, as well as the user interface project and budget allocation, will be heavily influenced by the training and documentation strategy. For example, if the training strategy is self-teaching on the job, then designing for guessability and learnability will require more effort, and the usability performance objectives (see Section 4.2) will likely have to be defined very stringently. Conversely, if intense training is planned for, then the training can address user interface design shortcomings and the usability performance objectives can be lowered. While the latter strategy may not be desirable from a quality user interface design point of view, it may nevertheless be a more cost-effective strategy from a business point of view. However, the reality of the train-around-the-usability-problem approach is frequently that users are well trained at roll-out, but users joining the organization later or changing jobs only get on-the-job training from co-workers. This may lead to inefficientsystem use and co-workers training their colleagues, instead of doing their actual work — a hidden cost. These trade-offs have to be brought to the attention of the Usability Steering Committee. The strategies and their implications for the user interface design must be documented, usually in a memorandum.

3.7. HARDWARE/SOFTWARE ENVIRONMENT

The hardware/software environment has usually been chosen by the time user interface work begins. At best, there is some flexibility in the choice of development tools. Understanding the hardware/software environment and the opportunities and constraints it offers will allow for implementable user interface designs. For example, if an application is to run on both large workstation screens and on laptop screens with half the capacity of the workstation screen, then decisions will have to be made about two software versions or one software version but with two different sets of usability performance objectives. If there is only one software version, then the user interface design has to address, for example, the scrolling problem created by the two different screen sizes.

In firefighting assessments, the usability engineer conducts a brief (one-day) assessment and documents it in a memorandum, indicating the trade-offs. In a fire prevention assignment, a more thorough assessment of the options and trade-offs can be conducted.

4. USABILITY DESIGN — BUILDING THE BRIDGE

The design process consists of four distinct project tasks:

  Defining the new user tasks (Section 4.1).
  Defining usability performance objectives (Section 4.2).
  Designing the system’s model for the user (Section 4.3).
  Designing detailed screens (Section 4.4).

Except for the definition of usability performance objectives, there are several tightly coupled design/prototype/evaluate iterations within each task, and there are also some iterations between these tasks. For example, discoveries in detailed design may lead to modifications of the user’s model or the new user task definitions, causing some rework in these earlier project tasks and possibly causing a revision of the usability performance objectives for these tasks. A frequent source of such causes for partial rework are idiosyncrasies of business process exception and error handling conditions. Another frequent source for rework is a change in project scope. For example, development of a part of the functionality may be moved into later releases of an application in order to meet the original roll-out deadline. If the usability design process addresses only the reduced functionality, then moving to full functionality may involve extensive user interface design rework to accommodate the full functionality in the user interface. This, in turn, increases the software development cost for later releases.

In most legacy system redesigns, users will quickly migrate from being novice users to becoming efficient users for many years to come (see Section 3.2). Therefore, it is recommended that designs first reflect efficiency of use and then address learning issues.


Previous Table of Contents Next