Previous Table of Contents Next


4. SOME SUGGESTIONS FOR MAKING SIMULTANEOUS USE OF THE WAR ROOM AND DESIGN PRISM METHODS

So far I have presented the Design Prism and the UI War Room as entirely separate entities. This form of presentation is as much for historical reasons as anything else, since these two approaches were grounded firmly in each of two separate design contexts. In the future, I plan to experiment with ideas for making simultaneous use of both methods. For now, I will just speculate on how I think this might be done. I leave the interpretation rather loose. It should be read in that spirit and in the spirit of maintaining multiple approaches/perspectives in design.

Let us start with user requests, as we did in the first stage of the original UI War Room. Paste these up on the wall. Prioritize the requests by team consensus or by another method if you prefer (e.g., you might want your priorities to reflect proportionately the number of users who requested an item, either explicitly or implicitly).

Instead of extracting and organizing user objects, as we did in the war room, this time parse the detailed task analysis data to yield Information, Objects, Goals, and Actions. This changes the “User Object Wall” into a “Perspectives Wall”. Make up your own perspectives if you want (but don’t use too many or they’ll become difficult to manage). Assign a color to each perspective, and write out every user element (Information, Object, Goal, or Action) onto its appropriately colored piece of paper. Organize these user element sheets on the wall… creating four separate hierarchies.

Create a high-level overview of the system from each of the perspectives, taking the organization of user elements on the wall as the basis for your design. Rearrange the elements to see how a different high-level view might change things. The view (or views) you create will be continually refined as more ideas come in from bottom-up idea generation processes.

Meanwhile, proceed on the whiteboard. Start bottom-up prototyping. Take one of the most important user requests, or take an individual user task, and gather together the user elements for that task/request. Focus on one color at a time. Lay out all the elements of that color on a table or a wall. Map out everything you think the user needs to understand that group of elements, continually adding elements of other colors to make the picture clearer. Make up new elements if you find that there is something missing (but don’t forget to make sure that these elements get posted back up on the Perspectives Wall, initialed with your name). Arrange the pieces of paper hierarchically or in sequence (or a bit of both) to show relationships between them. Write any additional information you need on or in-between these pieces of paper (use yellow stickies if it helps) to further define these relationships.

Get other people in the room with you. Use team members…bounce ideas off of each other. Get users to come in and help you out. If this isn’t possible, then use ideas you gathered from them when you went to see them during the task analysis. You don’t have to stick with their ideas if they don’t work. Look at previous versions of your own software. What was good about them? What didn’t users complain about? Have a peek at competitive products. Take ideas from software that has nothing to do with your own. If you’re stuck, try out something you’ve seen in another chapter of this book to help get yourself unstuck. Ask a colleague for an idea. Put on a funny hat.

Take the sketches you have created and plug them into your high-level overviews. If they don’t fit, then start a new high-level prototype. Keep iterating these top-down views to maintain the smallest (or most sensible) number of mutually exclusive prototype systems you can.

Once you have some of the main user requests covered, you are going to want to test out your ideas with users. However, at the moment you only have rough idea sketches, not concrete screen designs. Maybe you have the outline of a table, and possibly some of its headings, but nothing inside the table. You might want to test your crude sketches with a user or two (in fact, it’s probably a good idea), but at some point you are going to want to refine them a little. Here’s where the Design Guides come in.

Build up a Graphical Display Objects design guide. Start with a tentative guide early on in the process. Leave it rough, as sketches. Continue to iterate this design guide until the objects in it are well defined. Check it out with users, in isolation from the interface. What makes sense to them? Fill in your rough idea sketches with objects from this design guide, and continue to feed new objects back into the guide. Start to capture design rules that you are following, so that your colleagues can refer to them later on. Look up human factors research relevant to your users’ environment and write up some Information Coding guidelines for your interface. Refer to the look-and-feel style guide for your interface platform. Apply your knowledge of Human-Computer Interaction. Record the decisions you make and why you are making them.


Previous Table of Contents Next