Previous | Table of Contents | Next |
4.4. DESIGN PREPARATIONS
The report of usability work so far has primarily focused on the current state of the workplace. The results reflect the users current requirements, needs, and the shortcomings of the existing systems, but only vague ideas or hints of how the new system should support the work.
We now start the work of carefully restructuring the current work tasks and adding new tasks. The graphs are transformed into scenarios and/or new activity graphs that reflect the new way of performing the tasks. The activity graphs are often used as the starting point when writing the scenarios, but the scenarios also reflect the characteristics of the physical environment of the users. That is something that cannot easily be expressed in the graphs. The scenarios are also easier for outsiders to understand, and they are often presented to the users and customer in order to verify the services of the new system. Just as the scenarios are created to describe the future work tasks, the user profiles should be updated to define the skills and characteristics the future users will need.
One of the major mistakes of the case study was the decision to try to save time by not writing scenarios as part of the design preparations. The following inset contains a reconstruction of a potential scenario. The scenario illustrates how new tasks (in bold) are integrated into the current work.
Scenario for a Function Tester:
The function tester Tom enters the test lab one Tuesday morning. He is a bit late since he stayed late last night scheduling a break & destroy test. He had estimated that the test program would crash the system when the load reached about 10 000 simultaneous calls. He therefore specified a number of alternative tests that should be run at such a breakdown. Just as he suspected the test had come to a halt halfway through the normal path sometime during the night. With TSS 2000 it is not difficult for Tom to analyze the log containing the relevant parameters and to recreate the exact situation of the breakdown. He fills in the preformatted trouble report and attaches the relevant part of the log file and mails it to whom it may concern.
The usability team also developed design recommendations to capture needs and requirements from the user and task analysis that had not surfaced through work with the scenarios. Two examples are:
Problem Generally the users do not work as Function Testers for more than a year or two. The personnel at some test sites consist of almost no regular testers, only consultants.
Recommendation The initial impression of using the test tool must be positive. It must be simple to learn and use; otherwise, the testers will be reluctant to use it. It is also important to provide documentation and training courses that are adapted to inexperienced testers.
Problem Many Function Testers are newcomers that do not have the skill or the time to develop extensive test programs. The time between when they get their assignment and when the testing is expected to be finished is very short.
Recommendation Offer context- and syntax-sensitive help or prompting and include good support for reuse of old test programs.
4.5. USABILITY REQUIREMENTS
The usability requirements for a system consist of test cases and requirements that the system has to meet in order to be judged minimally usable. The test cases are based on the scenarios from the design preparations, and the measurable requirements are based on tests of the current and competing systems or are based on theoretical estimates. The test cases describe realistic work situations but focus on what work should be performed, not how it should be carried out.
The Usability requirements are set to verify how well the system should support the users in their work (Gould, 1988). The Delta Method focuses on five aspects of usability: relevance, efficiency, attitude, learnability, and availability (Löwgren, 1993). An example of a requirement would be to specify the time for completion of a specific task. Another one would be to specify the number of errors allowed in completing a task. It is not always possible to find good measurements of usability for each single test case. A set of test cases is needed to extend over all parts of the system and all usability requirements.
The project manager and the customer negotiate the usability requirements in the same manner as when defining the functional requirements. The result of this activity is the usability requirements that are a part of the requirements specification and a usability test specification describing how to verify the requirements. In the usability study we began with five test cases with associated usability requirements. One of them can be seen in following inset. These test cases did not provide comprehensive coverage of the complete set of system services, but rather those available in the first paper prototype. More test cases were added later and some of the initial ones evolved during the prototyping and usability tests.
Usability Requirements:
Test case: You have been enrolled in project Gizmo as a function tester. A number of test scripts have been prepared by a colleague. Use TSS 2000 to start the test script Alpha and increase the traffic load until the number of dropped calls reaches 100.
Relevance: 90% of the users are required not to invoke more than one irrelevant command.
Efficiency: 90% of the users are required to complete the task in less than two minutes.
Attitude: All users are required to prefer the new system over the present.
Learnability: The time spent using the documentation shall be less than 1 minute.
Availability: 95% of the users are required to find relevant help in less than 20 seconds.
5. BRIDGING THE GAP
The actual bridge across the design gap consists of two activities: Conceptual Design and User Interface Design. During the conceptual design the system services found during the task analysis are structured into an implementation independent conceptual model. This model is transformed into a paper prototype describing the actual layout of the user interface on the target platform.
Previous | Table of Contents | Next |