Previous | Table of Contents | Next |
4.1. NEW TASK DEFINITIONS
The process of building the bridge from the information described thus far to a reasonably polished design in the redesign of a legacy application is a rather systematic process. The first step in the design process is a quick storyboarding of the new user tasks with input from:
When storyboarding, it is recommended that emphasis be placed on the task flow, i.e., the steps with loops for repetitions, interrupts, and input/reviews/approvals. It is essential to identify common subtasks and key variations, e.g., regional differences and user preferences. In an object-oriented environment, the new user tasks typically correspond to use cases (Jacobson et al., 1994).
For each step, the following information needs to be identified, independent of any partitioning into screens:
To ensure scope control of the user interface design, it is useful to map the new user tasks onto the functional decomposition, if one exists. A functional decomposition, also called a process hierarchy diagram or a leveled data flow diagram, is a hierarchical breakdown of system functions. This ensures that there are no orphaned new user tasks (i.e., there is no functionality to support the task) and no orphaned functions (i.e., each function is used in at least one new user task). In conjunction with the database of user classes/new tasks/frequency (see Section 4.3.3), this information also allows the software engineers and capacity planners to fine tune their load planning. Providing this information to the project team is a good example of how usability engineering can contribute to software development.
If the redesigned legacy system provides a new front-end to the existing transaction-oriented back end, then the transaction codes must be mapped onto the new task definitions. This will ensure that every new task is supported by one or more transactions at the back end, and conversely, that every transaction is used in at least one new task. For example, at the XYZ Finance & Insurance Company, the new task definition for filling in application forms required some legacy transaction behind the scenes to retrieve customer data automatically for prefilling the forms. This addressed one malfunction of the existing legacy system, namely the duplicate data entry for existing customers.
The new task definitions are documented in a report. A complete list and a few detailed samples are posted in the usability engineering room. In the case of a fire prevention assignment, all the new tasks can be defined. In the case of a firefighting assignment, it is recommended that focus be placed on key tasks for key user classes and that they be developed as examples to be followed.
4.2. USABILITY PERFORMANCE OBJECTIVES
Usability performance objectives are modeled after system performance objectives, e.g., database throughput or acceptable levels of system availability. The key characteristics of usability performance objectives are that they make the quality of the user interface design measurable in a way that is meaningful for users and their organization. They are derived from the organizations business objectives (see Section 3.1) and the malfunctions of the current system (see Section 3.4). Usability performance objectives define the user interface design targets and the level of acceptable designs (Preece et al., 1994). They are posted in the usability engineering room. The most common usability performance objectives are targets for:
Typically, usability performance objectives are established for key tasks only (i.e., tasks that are performed frequently or are key to achieving business objectives) or for those tasks where errors have serious consequences. In addition, some overall ratings are usually included. For example, if staff turnover is high, then overall ratings will focus on guessability and learnability. By contrast, if fast customer service is essential and staff turnover is low, then overall ratings will focus on efficiency of use.
Previous | Table of Contents | Next |