Previous Table of Contents Next


The following example from the XYZ Finance & Insurance Company is intended to illustrate some of the points raised above. In the first round of navigation design, the clusters in the user class and new task definition/frequency matrix indicated that some user classes performed a fairly narrow range of advisory-type tasks several times during the day. Other user classes performed a wide range of tasks, with a core set of transaction-oriented tasks being performed many times during the day and a much wider range of advisory-type tasks being performed infrequently, i.e., once or twice a day.

A comparison of steps in all tasks revealed that both advisory- and transaction-type tasks had a common first step: the identification of a customer. As it was one of the client’s business objectives to provide a more personal service to customers, it was decided at the very outset that the customer should be identified on the opening screen as quickly as possible. A number of alternative means would be provided so that key information about the customer could be displayed. This would allow the user to form a picture of the customer quickly and then choose the service to be provided in accordance with the customer’s wishes. Displaying as much information about the customer as possible, as well as displaying sales suggestions generated by the program, had to be balanced with providing fast access to the large range of tasks.

With the XYZ Finance & Insurance Company project, in the next round of navigation design for each task, decisions had to be made regarding the use of chained windows vs. parent/child windows. Where task steps had to be carried out in strict sequence, chained windows were employed. Each window in the chain was considered a parent window. Child windows would pop up or be invoked by the user to handle exceptions. To move between tasks, including moving between suspended tasks, users requested a kind of task list, which included all the tasks touched upon in a session with a customer, and which, if any financial or insurance instruments the customer had purchased during the session. While moving back and forth between multiple windows/tasks is common in any windowing environment, the users had identified the requirement for displaying only one window at a time at full screen size. They were also concerned that the customers, who would also be looking at the screen, would be distracted by partially visible windows.

The matrix of user classes/tasks/task frequency, the opening screen, and the navigation principles are documented in the User Interface Architecture (see Section 5) and posted in the usability engineering room. In a fire prevention assignment, the matrix can be constructed in a computerized database, which can then be printed for display in the usability engineering room. In a firefighting assignment, the database is frequently constructed on flip charts that are posted in the usability engineering room or on a spreadsheet.

4.3.4. Vertical User Interface Design Second — Design for Each Task

The design for each task is accomplished through a combination of storyboarding scenarios and initial, rough screen layouts. These should not include the actual screen details. For example, “customer information” may be used, but not the actual fields such as first name, last name, etc. The focus is on identifying information that must be available at a glance and on the sequencing in which the information is generated (either by user input or system calculation/reasoning). Typically, a user interface designer provides a rough draft that is iteratively tested and refined with users and reviewed in JAD sessions, attended by the user interface designers, users, business analysts, and developers. The rough designs form the basis for the next usability project task, the detailed design. The rough designs agreed upon in the JAD sessions are also useful to the software development and quality assurance teams for the preparation of test cases.

The rough designs are documented in the User Interface Architecture (see Section 5) and posted in the usability engineering room. In a fire prevention assignment, rough designs are prepared for each task. In a firefighting assignment, rough designs are prepared only for key tasks.


Previous Table of Contents Next