Previous | Table of Contents | Next |
2.4.4. Flirting with Scenario-Based Design
During our task analysis, we had the good fortune of working very closely with one user, with whom we conducted an observational interview. We watched and listened as he reviewed in the space of an hour how he had solved a software problem report over 2 weeks time. The task information we recorded from this interview was heavily detailed.
I took the scenario for this one user problem and used it to drive the design directly. I designed a depth-first prototype (using very rough sketches) of an interface, based on the information we had gathered in the observational interview. I followed his process exactly, and simply mocked up part of a screen at each step that would fulfill what I perceived to be his needs during that step. I didnt worry about how full a screen was, because I was only intent on prototyping the part that our user was concerned with at that moment. I wasnt worried about originality at this point either, so I often took my drawings from other interfaces I had seen or from my own previous prototypes. This method kept me in a very creative, fast-flowing frame of mind. Every part-of-a-screen I designed would be labeled with an arrow pointing to the part-of-a-screen that came next in our users task. Sometimes I would just label a screen with a title and leave it at that. Other times I might have an option box here and a few lines of code there or maybe just a link to another tool (or a picture of a telephone so that he could call his buddy for help). Not everything I drew was going to end up on a computer, let alone in our software.
I ended up constructing a series of fairly illegible and incohesive diagrams...but this did not matter. The main significance of the effort lay in evoking the frame of mind of an individual user at his task and in helping me to generate creative new ideas that could be expanded upon later, during the more slow-and-steady periods of prototyping. The development of these screens also helped to give me a stronger sense of the order and sequencing necessary for our interface. It gave me a very definite method of approach that of translating our subjects verbal information into a prototype intended to capture all of the information he had given me. This forced me to be thorough in a new way: depth-first rather than breadth-first.
I was later able to transform some of the parts-of-screens I had created into more concrete prototyping ideas. In Figure 10.3, I provide an abstract view of the interface pieces I constructed (on the left) and how I might put these into an actual prototoype (on the right). In this example, the piece numbered 2 was used more than once in the users task. This meant that he was doing roughly the same thing at two different stages (though there might have been small variations in context), and needed the same sort of information or control in both spots. To support him in this, I decided to place sketch number 2 at the top of his screen as a static section of the interface while the other pieces of the task were arranged beneath, on two separate screens. The intent was to make his most-used task available from any screen. In ways such as this, I experimented with synthesizing the scenario sketches I had created into meaningful prototypes.
Figure 10.3 Abstract representation of a scenario-based design strategy.
We would have required scenario information from many more users if we had wanted to take the scenario-based design further and come up with representative user interface designs on this basis. Instead, the scenario mostly just helped me to generate new ideas, to step out of my current perspective, and to verify that our existing design attempts were on the right track.
2.5. PROTOTYPES
Most ideas would go through at least one iteration before they were tangible enough that we would feel comfortable posting them, autographed, on the Prototype Wall. We later found it possible to separate out mutually exclusive prototyping ideas that could not exist in the same interface. We developed these separate alternatives further in turn or in parallel as desired. If you consider the Whiteboard as the brainstorming stage, then the Prototype Wall represents the stage where as-yet-uncriticized ideas from brainstorming are evaluated and synthesized and are organized into a cohesive whole to meet strategic needs.
2.5.1. Choosing between Idea Sketches
Earlier, on the User Object Wall, I had placed the word module above procedure to represent the relationship between these two concepts (Figure 10.2). The next part involved mapping these relationships to the interface prototypes themselves (using the whiteboard). A number of representations of the relationship could have resulted. We could have indented procedures in a list directly beneath each module name (Design 1, in Figure 10.4), or, we could have used a box (labeled with the module name) to encompass all of the procedures within a module (Design 2). There was no deterministic process for choosing which idea sketch would make it into a prototype. For the most part, we used informal criteria to help us decide which of the proposed methods to use. Screen real estate was of concern, for instance, so one of the more convincing strategies was to list procedures beneath a module name and to make the module names collapsible (Design 3; similar to Macintosh file directories). The user could then decide whe ther or not they needed to see the procedures within that module.
Figure 10.4 Three possible designs for module encompasses procedure.
In retrospect, a better-defined decision method such as the Questions, Options, and Criteria (QOC) method (MacLean, Young, Bellotti, and Moran, 1991) could have helped us, at this stage, to formalize and record our decision-making process. A QOC-type method would have forced us to standardize and document the issues (Questions) we considered in deciding which alternatives (Options) to keep. It could have made clear the link between these options, the Criteria we used to evaluate the issues, and the choices we made. A formal decision-making method most likely recorded after, rather than during a design session (so as not to stifle creativity) would help with maintainability of the interface design over time.
Where possible, the choice of designs could be left up to the user by placing design alternatives into separate prototype systems or by performing formal usability testing on the different options.
Previous | Table of Contents | Next |