Previous Table of Contents Next


4.4. DETAILED DESIGN

Detailed design requires the detailed data models and functional specifications developed by the systems analysts and designers. It follows established design principles (e.g., the appropriate widget to choose for making a selection) and design guidelines (Preece, Rogers, Sharp, Benyon, Holland, and Carey 1994). The author’s experience has been that using vendor guidelines such as MS Windows or Motif lead to diverse (i.e., inconsistent) designs across a team of developers because there is often wide latitude given for making choices.

For example, several teams of developers at the XYZ Finance & Insurance Company were working on the design of independent modules, each representing both a set of related user tasks and a functional area. Users would be using the modules in various sequences as the need arose. Common data were exchanged automatically in the background to avoid duplication of data entry. One of the vendor guidelines was used to ensure consistent user interface design. During the user interface design phase for the modules, there was very little contact between the different development teams. They assumed that it was not required because all teams were using the same guidelines. The first usability tests requiring users to use several of the modules revealed that different developer teams had used “Cancel” in three different ways: to cancel all data entry on the current window, to cancel all data entry on screens in a chain of windows, and to cancel all data entry in a module. While all three ways of employing Cancel are permitted under the guidelines, the effect of the Cancel is no longer predictable for users. An alternative design was developed that indicated clearly to the users which data entry and actions were canceled (different words were chosen for the three types of Cancel).

An application-specific style guide (see Section 5) with a computerized prototype example that considers user classes, tasks, and implementation tool capabilities and constraints is required to obtain consistency. It must be coupled with tight quality assurance for conformance to ensure usable designs. The prototype represents the concrete user interface design. The scope of such a prototype usually includes the opening screen and the detailed design for one or several key tasks. If the dialogue design is well thought out and tested, no more than two iterations should be required for detailed user interface design and testing. Additional detailed design is required for learning use and error prevention.

In fire prevention assignments, the application-specific style guide and proper user interface specification can be developed (see Section 5). In firefighting assignments, it is recommended that effort be placed on producing the application-specific style guide with one or two computerized prototyped tasks. Often developers will require training to use a style guide effectively, with additional, ongoing coaching during the development process. The prototypes become “sample” user interface specifications.

4.5. TIPS FOR MANAGING DESIGN ITERATIONS

It is best to time-box user interface design effort according to the overall project plan and budget. On a fire-prevention type user interface project, three to five iterations are usually required to reach a satisfactory design, i.e., a design which meets or approaches the usability performance objectives. On a firefighting type user interface project the number of iterations is severely limited. Typically, one or two iterations have to focus on the most glaring usability problems at the navigation level.

For both kinds of projects, tight user interface project management is essential to control the number and duration of iterations. At the end of each iteration, the design approach and rationale must be documented, including rejected ideas and the reasons why. Results from tests against usability performance objectives must be documented in order to show design progress. Each usability problem uncovered in a test must be rated like a malfunction (see Section 3.4). Last, but not least, there must be agreement on the usability problems that will be addressed in the next iteration (because it is usually impossible to address them all) and why (i.e., based on the criticality of the problem).

5. USABILITY DELIVERABLES — DOCUMENTING THE USER INTERFACE DESIGN

In the author’s experience, the user interface design should be documented in three distinct deliverables:

  User interface architecture (Section 5.1).
  Application style guide (Section 5.2).
  User interface specifications (Section 5.3).


Previous Table of Contents Next