Previous Table of Contents Next


2.5.2. Concurrent Top-Down Iteration

So far, most of the discussion has centered around bottom-up processes of design. At the same time as we were sketching ideas for features, we were also designing (and iterating) the high-level structure of the system’s interface. We worked with the user requests, early on, to determine high-level categories within which we might best classify our user objects. To illustrate: at first we tried classifying our user objects into eight categories which covered all of the high-priority user requests: Data, Definition, Calls, User Interface, Control, Structure, Runtime, and External Information. We tried placing each of our objects into one of these categories. We stopped after less than half of the objects had been classified, feeling that the number of categories was increasing out of control and that the user objects were not fitting as well as we had hoped.

We began to feel blocked from our goal and looked for some other way in which to determine the key features of our prototype, and reduce the number of categories. Eventually, we ended up taking a hard look at our list of categories, and waded in with both feet to do some pruning. We decided that User Interface objects were not really major features of the tool, but that they would form its structure instead. We removed Control as a feature, because control flow and the order of procedure calls could be shown within the Calls section of our interface. We then decided to remove the External Information category, since it contained objects to which we would connect our tool, rather than features of the tool itself. Finally, by combining the Data and Definition pieces, we had cut the number of categories in half. We were left with Calls, Data/Definition, Runtime, and Structure as our major, structural features (see Figure 10.5).


Figure 10.5  High-level prototype idea sketch.

Later, as we did some more bottom-up prototyping, we found that it made sense to reorganize the high-level structure we had created. We now combined the Calls and Data pieces, instead of the Data and Definition pieces which were combined earlier. This changed the high-level categories to Cross-reference, Definition, Runtime, and Structure. Iterate and iterate again.

It was important to keep re-defining our interface at the top as well as at the bottom. For instance, if we had prototyped a Cross-reference part of the tool, without explicitly defining at the top-level that we were combining the Data and Calls, then the front end of our prototype would no longer have been in synch with the individual prototypes for each feature.

2.5.3. Separating out Mutually-Exclusive Prototype Systems

It is important that alternatives be explored in prototyping, for at least a couple of reasons. First, more than one prototype should be tested with users: It is too easy for a user to quickly say, given a single prototype, “Sure that looks good”, leaving the designer with little valuable feedback. Second, many good ideas will come up during prototyping sessions, from a variety of sources. Not all of these ideas can possibly fit together into a cohesive whole. Some ideas will conflict with others.

We had a number of team members working on the interface. Most of the work in the early stages of the war room was being done by myself and by one of the software developers on the team: myself, because it was my responsibility as user interface designer, and the software developer because he had the time and the interest. To this point, the two of us had spent most of our time working together on a single prototype system (the one in Figure 10.5), with our view narrowed to the completion of this one framework.4


4It should be noted, though, that many of our spur-of-the-moment, right-then-and-there ideas didn't fit within out main framework and were left sitting around like leftovers waiting for the right high-level prototype to pick them up.

Other members of the team were also encouraged to use the war room and to post their ideas there. Some had been working in parallel on their own high-level views of the system. Feature ideas had been stewing throughout the previous release cycle, to the point where team members had even coded fairly sophisticated computer prototypes of potential features. These prototoypes were considered valid and valuable contributions to the war room — but they were given no more weight than rough paper sketches.

Once a fair number of prototyping ideas were up on the wall, we were able to pick through the pieces of interfaces, organizing and rearranging them to come up with the smallest number of mutually exclusive systems possible. Some of the pieces represented different (or overlapping) ideas for one feature and, therefore, were unlikely to appear in the same prototype system. Other sketches could fit in any of the alternative systems, so the distribution of these pieces became an executive decision based on best fit. Still other pieces might end up in all of the alternative systems, if no other ideas were generated for that particular feature.

We ended up with six different prototype systems — where each alternative system could not be fully meshed with any of the others. Even so, pieces of systems could still be moved around, from one system to the other. As each of the systems was developed in more detail, the number of alternative systems could grow or contract as appropriate.

2.5.4. Matching User Requests to Developed Features

Once we had identified and developed a paper prototype of a system (however rough), we could then take individual user-request and user-object sheets and paste them on the prototype. In this way, we verified that important features were being covered and that the interface was built on user information, rather than on intuition alone. Simple as this may sound, pasting the sheets on the prototypes represented the completion of this part of our journey, for all we meant to do was to make our way across the room. Later, of course, user evaluation and iteration would occur. However, for the time being, the UI War Room process had given us some large and practical stepping stones to get from user information to first-draft concrete designs.


Previous Table of Contents Next