Classic Book: Contextual Design
Defining Customer-Centered Systems

Hugh Beyer and Karen Holtzblatt
Morgan Kaufmann, 1998

ISBN 1558604111 (paper)

Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
 

Other Reviews

For a book and a method that are all about (software) design, a remarkable amount of fresh and practical advice is given on stakeholders, viewpoints, scenarios, requirements, and prototyping -- to mention just some of the more obviously RE-oriented parts of the book. A dead giveaway is that Part 5 is headed System Design, so the earlier chapters must be about something else!

So, Contextual Design is plainly about much more of the life-cycle than it sounds. One has to wonder whether this isn't a case of designers reinventing RE, but the bibliography shows that the authors were reasonably well-read -- being aware of RE and authors like Jackson, Potts, Sommerville, Easterbrook -- not to mention Polanyi, Suchman, Schön -- and have therefore simply got their own philosophy and practice. The philosophy is covered explicitly in the reading list, and homespun snippets are sprinkled liberally through the text -- B&H quote themselves rather than other people! For instance, 'Individuals play multiple roles'; 'Users have to be the glue between incoherent systems'; 'support the natural alternation between doing and reflecting' (surely they must have read John Heron on Co-operative Inquiry to say that?).

The book is carefully designed, and organized into 6 parts:

• Understanding the Customer, which explains what Contextual Inquiry is and how it works;
• Seeing Work, which talks about modelling work in five overlapping ways - flow, sequence, artifact, cultural, physical;
• Seeing across Customers, which shows how to get things to work for more than just individuals: 'It's remarkable that systems can be built to support large numbers of people at all', is how it begins; you have to induce rules about populations from a few instances and events. The five models are revisited and 'consolidated';
• Innovation from Data, which also revisits the five models, showing how new systems always mean redesigning people's work;
• System Design, which tries to base design on user environment design. There is much to commend in this attempt, but it really isn't true that all system behaviour can be identified from the user environment, let alone all the non-functional stuff. Heavily algorithmic software like weather models or flight control systems needs to be described in terms of mathematical physics, not just in terms of the behaviour of the human forecaster or pilot.
• Prototyping, which discusses how to get direct customer feedback again, as use cases do, except that the authors think that scenarios are not nearly enough: 'Other forms of communication such as use cases and scenarios attempt to communicate more of the context of use. These methods tell stories of how people will work in the new system, so they communicate better than a model or specification. However, each scenario can only tell one story out of the many the system must support. And they all suffer from the same basic drawback: most customers have only an unarticulated knowledge of their own work and cannot check a proposed design against their own experience unaided. ... They'll help answer the question, "What matters to the customer?" but not "How should the system be structured for them?" To provide that level of feedback, customers need not just an artifact but an event, a process that will allow them to live out their own work in the new system and articulate the issues they identify.' (pages 369-70) Scenario-lovers will rightly respond that a scenario approach means more than just artefacts, it means workshops and role-play and participatory design -- and Beyer and Holtzblatt would roundly agree.

This is a book full of sound practice and common sense. It has much in common with Scenario-Based Design -- more, perhaps, than the authors would recognise -- and is based on a wealth of experience. I am always astonished how many ways of being there are in the world -- like a 17th Century Explorer mentioned by Bruce Chatwin, the requirements engineer should always wonder 'What is it that you do, and how is it that you live?'. This could be the philosophy of Beyer & Holtzblatt when looking at a new organization and work context; it also expresses my surprise that someone is doing something so like RE with such a different outlook. The authors also have a tremendous and obvious enthusiasm for their work, which shows up in the Chicago Gangster-style portrait at the back of the book as well as in the strong, focussed and energetic text.

Everyone interested in helping people develop better systems should get a copy of this important book.

Postscript: there is a chapter by Karen Holtzblatt in Scenarios, Stories, Use Cases, and the book compares different scenario approaches on the basis of project size, type, and position in the development life-cycle.

© Ian Alexander 2002, 2004