Previous Table of Contents Next


5. BENEFITS, LIMITATIONS, AND DIFFICULT QUESTIONS

In both of my interface design contexts, the intent was to redesign an existing system, based on some underlying structure (whether software or hardware). Are the structural techniques I have chosen only useful for incremental design then, or can they lead to innovation as well? Though I think that both of the design methods could provide a framework within which to pursue innovative design, they might need to be supplemented by other techniques, such as those presented by Colin Smith (Chapter 11). In both cases, my design context was fire-preventative, rather than fire fighting. We had the luxury of time available for creating design guides, filling in tables of relations, and designing from multiple perspectives. These techniques may not be well suited to a more fire fighting type of UI design context.

Perhaps more to the point, it is questionable whether any designer other than myself would be willing to go through the process of creating the tables I have created. It is easy enough to put together tables of one’s own design, but when this becomes a step-by-step process dictated by somebody else, it loses some of its charm. Mind you, Table 10.4 (which I used in detailed design), was recommended by a supervisor, and still I found it to be a very useful structuring tool.

I think it is important to question whether my approach to display object design — through design guides and tables — can function outside of a power plant context. The technique is certainly adequate and well-suited to dealing with precisely-definable physical mimicry, but I am less sure whether it would be expedient to use outside of this context (except later in interface design or for maintainability). It may also be desirable — rather than opting for consistency — to maintain a variety of different graphical objects in early prototypes, so that these can be shown to users. In our case, the early definition of design guides was essential, because the graphical objects we defined were going to be used by many software designers (physically removed from each other and from the human factors professionals) in a safety-critical interface.

There is some question in my mind whether the perspectives of the Design Prism do indeed expand a designer’s view, as I have claimed, or whether they just limit it in a new way. Could approaching design so intently from these four perspectives merely limit the sight of the designer from other ways of thinking? In addition, what does it mean to the consistency of an interface if one screen is developed from one perspective (e.g. user Goals) while the next is developed from another perspective (e.g., Information). Simply being aware of this issue may help to circumvent potential problems. At the same time, I continue to question whether the war room’s User Object Wall wrongly predisposes the interface to being hierarchical in nature, by forcing the organization of objects into tree-like structures. How would the User Object Wall deal with a sequential task, like a software setup screen? How about a networking task? Need there be such an emphasis on hierarchical design, or is it just that hierarchical structures are consistent with human cognitive organization of information? How many other types of interfaces can we imagine? What is stopping us from imagining them?

I see a tension between structure and creativity in design. To maintain consistency, it is sometimes necessary to sacrifice originality and vice versa. Is there necessarily a trade-off between creativity and structure? What is the appropriate balance?

One particular strength of the Design Prism approach is that it provides a method for generating ideas from different perspectives, even when users are inaccessible or other team members are not available for creative input. This supports the designer in her difficult task of developing a number of creative ideas, in parallel, over a period of time. Perhaps the most promising aspect of the Design Prism is its unique approach of creating — simultaneously — a number of alternative designs. This may not entirely solve the problem we have of funneling alternatives into single solutions, but it certainly supports a designer’s attempt to challenge some of the limitations of tunnel vision.

The main strength of the User Interface War Room is its use of space in structuring the design approach. The setup of the war room enables the designer to survey User Objects, User Requests, and various prototypes (completed or under construction) just by turning his head. The User Object Wall allows the designer the flexibility to quickly organize and view relationships between objects. The use of space helps in maintaining creativity in design. Some attempt is made, in the Whiteboard section of this chapter, to document the creative process of idea generation (though there is still a long way to go in this direction). Finally, it seems that the war room approach would be particularly amenable to participatory design with users. The structure is fun to work with, easy to use, and easy to learn (as is the Design Prism).

I think I have found some practical ways to bridge parts of the design gap… or to at least make the leap seem a bit more manageable. Despite my efforts, there is still a lot of magic to my methods. They have little to say about how to design the flow and navigation through an interface. They fall short on multimedia aspects of design. There is no suggestion in them as to how one might develop an interface that users find engaging or fun to use. There still remains a fairly sizable leap from the organization of user objects (or user elements) on the wall, to the idea sketches themselves.

In the introductory chapter of the book Taking Software Design Seriously, David Wroblewski considers the construction of human-computer interfaces as a craft. In keeping with this notion, perhaps then apprenticeship is one of the best methods for teaching this craft. I still firmly believe that we need to try to push ourselves to create well-defined and contextualized tools that can be used by beginners (and experts) as stepping stones toward the other side of the gap. However, I also consider myself fortunate to have started my own career in an apprenticeship-type position — where I could supplement the structure provided by a few walls and a handful of articles with somebody else’s magic.


Previous Table of Contents Next