Previous | Table of Contents | Next |
3.2.4. Storyboards and User Interface Flow
Storyboards were used in two ways on this project. First, they were used within the design team as a working tool for sketching out user interface flows and navigation. In this case, the storyboards were often hand-drawn User Interface sketches on sticky notes arranged in possible flows placed on large sheets of paper. The context for each individual display was its use-case and scenario of execution. Because the use-case analysis defined relationships among use cases (as shown with the extension relationship for the example in Figure 3.5) the user interface flow from screen to screen was aligned with the scenarios of use and in turn the end user goals. As these were reviewed by the design team changes were made, and questions and issues were noted right on the storyboard for later resolution.
Once the design team felt the storyboards were reasonable approximations of the system they could build they were captured as black and white drawings with a computer drawing package. These more polished assemblies of screens were used to conduct storyboard walkthroughs with end users. Four of the original companies, and a total of ten users, participated in the walkthroughs, which took between 3 and 6 hours to cover about 30 total use cases. The walkthroughs combined an opportunity for the end users to play through the paper prototype and for real-time design. Storyboard review is particularly useful for covering a large amount of material and providing for both detailed screen design review and overall work flow discussion. The joint walkthrough-design sessions often empowered users to elaborate on their work practices and then to describe their own visualizations of interface designs. Comments often provided straightforward alternatives designs. For example, users pointed out a relationship among a group of objects they felt was central to how they worked and suggested this relationship should be captured (e.g., hierarchical organization in a tree view). Thus, two critical types of data were gathered. First, initial usability data were gathered where were users confused? Where did they make errors in trying to walk through the design? Second, the users could talk about how they would use the capabilities embodied in the design and describe how it integrated with their work practice.
3.2.5. Usability Goals
It is a great help in design and testing to establish early on some goals for the usability of the system. Usability goals provide measurable targets for the design and give a development team a tangible expression of the desired system behavior. Scenarios, as stories, can provide the context for defining tasks and goals. Two example goals (drawn from a set of about 30 goals) are defined below, using the same data from which other elements of the design have been motivated.
These goals were tested with the prototype application, as described below.
3.2.6. Prototype and Field Testing
Besides the storyboard walkthroughs, two other steps were used to gain user feedback. A Visual Basic prototype was created about the same time a first draft of the storyboards was available. This prototype was tested with five operators in 1-hour sessions. Test results provided many comments about how the linked navigation needed to work, how status should be indicated, and how transition from monitoring and detecting problems to problem resolution should be supported. Regarding the usability goals, users were able to note events as desired and quickly access the event detail information. However, they needed additional color coding for status indication and it took practice to discover some of the navigational mechanisms used.
Field test of preproduction versions of the software revealed relatively few new comments when conducted with users who had participated in the storyboard walk through. On the positive side this indicated that early and repeated inclusion of user feedback can help resolve problems. On the negative side, because these users were more experienced with the application design, their feedback was not representative of that from naive users. For a variety of reasons subsequent usability testing with naive users was not done.
Previous | Table of Contents | Next |