By Gerd Waloszek
This review takes a personal look at Karen Holtzblatt’s and Hugh Beyer’s book Contextual Design.
|Hugh Beyer & Karen Holtzblatt
Contextual Design: A Customer-Centered Approach to Systems Designs
Academic Press, Inc., 1997
ISBN: 1558604111 (Hardcover)Usability: Methodology – Contextual design, User task analysis
|Karen Holtzblatt is the visionary behind InContext’s unique design approach. Karen’s combination of technological and psychological expertise provides the creative framework for transforming a marketplace with innovative designs. Karen is recognized as a leader in the design community, having pioneered innovative ideas and approaches throughout her career.Hugh Beyer provides the technical expertise to support InContext’s design solutions. His extensive understanding of the unique and varied capabilities of a wide range of technical platforms enables InContext to design innovative solutions in virtually any development environment.
(From http://incontextdesign.com/people/karen-holtzblatt/, shortened)
At the CHI 2002 conference in Minneapolis there was a panel called “CHI@20″ that addressed the future directions of the conference. The panelists bemoaned the lack of theories, especially generative ones, in the user interface design field. When the panelists were asked for an example of a generative theory, Ben Shneiderman named Karen Holtzblatt’s Contextual Design methodology. Here is a review of the book that presents this methodology – and who else could have better recommended it than the winner of the CHI lifetime achievement award Ben Shneiderman.
Karen Holtzblatt’s and Hugh Beyer’s book Contextual Design is probably one of the “must have” books for user interface designers, especially for those, who go out to the customers and observe work practice. In this review, I provide a short overview of the book and the methodology and also add a few personal observations and experiences.
The primary goal of the methodology is to base design decisions on real data, not on assumptions or personal preferences. Part one of the book provides a general introduction to methodology, conducting customer site visits, and interview techniques. At the heart of the methodology, there are five work models. These models are presented in part two of the book. They are derived from the data gathered at different customers sites: the physical, cultural, artifact, sequence, and flow model, each of which captures a “face” of work – plus the affinity diagrams, which assemble and consolidate data that did not fit into the work models and serve to retain design ideas.
I had the opportunity to take part in a course led by the authors of the book. One of the aspects that impressed and somehow shocked me most was: the real focus was not on designing an application but on redesigning work practice. The flow model that makes this most obvious: I realized that in the process of reorganizing work we were making jobs and people obsolete that in the current work practice were important and often well respected nodes within the process network of a company.
Figure: Examples of flow model (left) and UED (right)
The models are consolidated and used to drive the design process; the consolidation process is described in part three of the book.
Visions, story boards, user environment designs (UED), and prototypes are further steps in the design process (these steps are described in part 5-6). Ideally, they lead to innovative software solutions and work practice. I like the UED most because, before I learned about Contextual Design, I already used structure and navigation graphs to model applications. The UED goes beyond this and acts as an abstract “floor plan” for an application: It has “rooms” that offer certain functionality and there are links between the rooms that describe their relationships and dependencies. A UED can fairly easily be translated into the language of user interface elements and then tested in a prototype. One of my favorite notions here is that the translation can be done into any interface technology – the UED is independent of UI technology. So, those UIDs or developers who claim that they urgently need a certain control, otherwise they would not be able to implement their “cool” application, are proven to be wrong. Substitute solutions may not be the best ones, but there is always a workaround. As a consequence, the mapping or implementation part of the design process, which is often the part that user interface designers spend most of their time on, resides in chapter 18, From Structure to User Interface, that is, close to the end of the book. It presents three examples of mapping an UED to different UI technologies – not much for technology freaks…
Finally, chapter 20, the conclusion, is called Putting It into Practice – this title summarizes probably one of the greatest challenges for user interface designers after reading the book or taking a course in Contextual Design.