Previous | Table of Contents | Next |
1. INTRODUCTION
1.1. WHY THIS CHAPTER
I began my career in Human-Computer Interaction both thinking and writing about the topic of this book. One of the first documents I wrote at work was entitled Techniques for Translating User Task Analysis Information into User Interface Prototypes. It was written as an attempt to fill a hole that I had perceived in the existing literature on the topic. I had just recently entered the field at this point, and I think my very naiveté gave me a valuable perspective for the writing. I knew what I needed to know, and I knew what wasnt there. There was a lot of magic a skill that I hadnt yet developed in this thing called interface design.
My first position was an apprenticeship-type position with a user interface specialist at a telecommunications company. We were working on the design of the interface for a computer-aided software engineering (CASE) tool. We had just completed the first formal user task analysis this tool had ever seen. As a result of delayed software releases, our UI specialists vacation time happened to fall right when we were about to take all of our carefully gathered user information and turn it somehow magically into concrete design.
Id seen designs before, of course theyre all around you when you turn on your computer. There were even some good rules-of-thumb to help me assess whether the design I created was halfway decent or not. But now that I had some good, solid user data on which to base a design I didnt know quite what to do with it.
I had discovered the gap, and I hadnt the magic necessary to get me across.
I searched the literature, and it was then that I become aware of the surprising scarcity of guidance that deals directly and practically with this crucial aspect of the design cycle. I began to pay close attention and to document the techniques my colleagues and I were using. Since that time, I have continued to evolve these techniques on my own and to monitor their successes and their limitations.
1.2. DESIGN CONTEXT
For the sake of clarity, I will make a distinction between the two different work environments in which my user-interface design techniques evolved:
The User Interface (UI) War Room method discussed in this chapter is based on my telecommunications research. The Design Prism approach was originated during interface design and analysis for the power plant. In the sections that describe each of these methods, I will further define the design context in which the work was done and on which the method is based.
The design context presented in these sections is meant to situate the design recommendations presented in this chapter and give the reader a sense of the conditions in which an approach has been effectively used. The techniques presented may be more suitable for some design environments than for others. I do not believe that we should be looking for a single method of design as much as for a set of tools that can be used under particular circumstances. I encourage the reader to try out the methods used in this chapter and to try combining them with other methods from this book and from personal experience. Each interface design project is unique and different circumstances call for different measures.
One of the ideas which has taken form in my methods is the exploration of multiple perspectives... multiple ways of looking at and approaching design. In this spirit, I present two different techniques that I have found to be useful in practice the User Interface War Room and the Design Prism. I would ask you to consider these two methods separately to begin with, since they were developed under different circumstances. After Ive introduced and explained each of them, I will give some suggestions on how they might be used in conjunction, based on my own future intentions to explore.
2. THE USER INTERFACE WAR ROOM AS A METAPHOR FOR INTERFACE DESIGN
A user interface war room is an affectionate way of describing a room dedicated to the purpose of getting ideas to flow freely, putting them up on paper, discussing them, and ending up with paper prototypes of a system. When our design team acquired just such a room, I began to use it as a metaphor for the interface design process I originally documented in my telecommunications work.1
1Though we were fortunate enough to have the use of a dedicated UI war room, the methods described in this section could also be used in the absence of such a room.
Figure 10.1 shows a picture of the room, to give an idea of its layout. As you can see, this is your standard four-walled room, with floor and door. Each of the walls in the room was designated for a particular step in the design process.2 At this stage of the cycle, we had already extracted key user requests from our task analysis interviews and documented them in an overall user task analysis report. These user requests were prioritized and placed one user request per sheet on the left-hand wall of our UI war room. On the back wall we pasted user objects. These came directly from the interviews. They were things like module, architecture diagram, key element, layer of software words that represented some sort of concrete conceptual item to users, in their language (our users were software developers). We took these objects and arranged them on the wall to show hierarchies and interrelations. Then we would flesh out some creative ideas on the whiteboard (usually working with a partner) and post the more refined ideas on the right-hand wall. We constructed and refined higher-level, top-down views of the system, while at the same time developing the sketches that came from bottom-up styles of idea generation. In the end, we could check the resultant paper prototypes against the user requests and user objects, to make sure that the prototypes reflected the user needs and information we had gathered.
2The reader might find it interesting to compare the war room we set up here to the room described by Karat and Bennett (1991) in their four-walls design environment, which I have since come across. The walls of their room were designated for Scenarios, Design Constraints, Open Questions, and Design Sketches.
Figure 10.1 The user interface war room.
Previous | Table of Contents | Next |