reg:exp

Notes on "Contextual Design" (Beyer, Holtzblatt) - Part 1

Contextual Design
Hugh Beyer, Karen Holtzblatt
Morgan Kaufmann, 1998
ISBN: 1558604111
Info: google print | amazon | bibtex

Summary graphic of the approach from the authors' website:

Below is a summary of Beyer and Holtzblatt's main points in the first two parts of the book which are concerned with data collection in the field and initial processing and interpretation of that data. Chapters concerned with turning observation data into design ideas will be summarized as the need arises in our project.

Chapter 1:
Agony comes from not having a ground for making descisions or evaluating alternatives. Data breaks this deadlock. Data is the only reliable outside arbiter for people. But don't just ask what people want - you need a bidirectional conversation.

Chapter 2:
Marketing does not provide the right kind of data to make design decisions - it does not answer questions about the structure of a system. Marketing data gathering techniques may not be useful for the same reasons - they assume the right kind of questions are known a priori and the task of the data gathering is to find answers. Design exploration first has to find the right questions. A hard goal: make customer intuition explicit. You have to see work as it happens to reveal all aspects of it - contextual inquiry is the technique to do just this. CI gathers data in the field from a small number of participants. The goal is to then generalize form the observations. Principles of CI: context, partnership, interpretation, focus. Typical form is the contextual interview - 2-3hrs, introduction, observation with interruption, examination of artifacts. 10-20 interviews total are a good rule of thumb to cover an area of work.

Chapter 3:
Core premise of contextual inquiry: go where the customer works, observe, and talk to the customer about the work. The master/apprentice relationship model is especially useful for collecting data. Acting according to a relationship model is more effective than memorizing interviewing techniques and strategies. Explaining while doing is easier for the "master" than conceptualizing and abstracting their tasks - in the latter case, details get glossed over. Seeing the work reveals what matters, details, and structure. Remember: we don't just observe to understand and learn the tasks, but to then support them with new design.
Context: being at the place of work allows for gathering ongoing, concrete data. Summaries of experiences are not rich enough to generate data relevant for design. Abstraction: "If the customer is leaning back and looking at the ceiling, he is almost always talking in the abstract." Cure: "constantly pull the customer back into real experience". For retrospective accounts, ask questions that prompt interviewee to fill in the skipped details.
Partnership: in many interviews, control and power over conversation resides with interviewer - CI reverses this imbalance. What the interviewer offers: giving the interviewee a better understanding of their own work. Share your ideas that arise during interviews immediately so that your mind is clear and you get on-the-spot feedback.
Interpretation: Data gathering is not enough - you need to interpret the results to generate good design ideas. "Interpretation is the chain of reasoning that turns a fact into an action relevant to the designer's intent." (57) How can one insure the interpretation is right? Share it with the customer while they are engaged in the work - they will validate, refine, or reject it. Listen for "Huh"s, "Umm..could be" and "buts" in the responses.
Focus: necessary framework to make sense of work - set a deliberate project focus; each person also brings in their particular focus. Use group interpretation and interpersonal triggers (?). Listen to internal signals to find situations in which you should adjust your own interpretations: surprise and contradiction - always assume that a "seemingly pointless action hides a key secret of the trade"; Nods: look not for agreement, but for possible divergences; what you don't know (Technical jargon): admit yor ignorance! you are out to challenge your assumptions, not to validate them.
Structure of the contextual interview (p.64): most commonly one-on-one, 2-3hours; four parts:
1) conventional interview: introduction, summary data, 15 minutes.
2) transition: state rules of observation and introduction - 30 seconds.
3) contextual interview proper: keep it concrete, be nosy, take lots of notes
4) wrap-up: skim over notes, summarize with interviewee (15 mins).

Chapter 4: Contextual Inquiry in Practice
Set focus first - transform solution requirements into statement about the customer's work. What is the work we expect to support? How does this work fit into the customer's whole work life? What are the key work tasks?... (p.68) Who is involved in the work? Where does it happen physically? Study analogous work situations - look for metaphors {exactly what we are doing with the photo documentary} to expand focus. Inquiry starting points for commercial software products: designing a known product/addressing a new work domin/introducing a new technology. For IT project: upgrades/new systems/process redesign. Designing the interview situation - different kinds of tasks:
- normal: use standard CI
- intermittent: ask user to keep log
- uninterruptable: videotape, review with customer later
- extremely long: interview range of users at different stages of process; do retrospective walkthrough with a few; use project artifacts
- extremely focused: videotape and interpret with user
- internal- get at mental processes by interrupting a lot.
Who to interview: 2-3 people in every interesting role; 10-20 people total; 4-6 businesses for variety - go for diversity. Look for different business strategies (frelance/constultancies/large companies); cultural differences; physical/geographical situations/diffrerences of scale; *come up with short focus statement in simple language (77)*.

Part 2 - Chapter 5: A Language of Work
Formal languages are good; graphical formalisms are especially suitable for design - but not all are appropriate (cf. Nardi). The authors advocate their "work models" - five types of models are: flow, sequence, artifact, culture, physical - all are described in the following chapter.

Chapter 6: Work Models
Models describe work from the point of view of the interviewee - individual perspective.
The Flow Model: no work happens in isolation - the flow model makes communication and coordination explicit. Work flow model elements make the following distinctions: nodes (“bubbles”) are individuals or groups; their responsibilities are summarized within the node; flow is communication and passage of artifacts – shown as arrows. Artifacts themselves are boxes on top of flows. Communication topics and actions are shown on top of flows without boxes. Places are rectangular nodes with only incoming arrows(?). Breakdowns are shown as lightning bolts. Things to watch out for: coordination with other people – all contacts should be represented. Roles – what responsibilities are people taking on in practice (these are rarely identical with their formal job description). Informal structures: implicit and engrained actions that happen without reflection. Pay attention to real interactions – not the handbook definition of how things should be done.
Sequence model: understanding intent facilitates interpreting the steps taken to realize that intent. Sequence models are similar to flow diagrams or task analysis but make intents and triggers explicit. The show the linear ordering of events as perceived and acted upon by an individual – patterns and repetitions are handled later during consolidation. Graphical elements: intent on LHS of sheet; triggers as events in linear sequence; steps; order loops and branches by connecting steps with unlabeled arrows. Breakdowns are marked with lightning bolts as before. Finding the right level of action recording for your project. User hesitation and error are places where tools do not meet their understanding of the work process – these are design opportunities. Automatized systems have to provide triggers that are analogous to the physical world – users need reminders to take action. Infer intents after writing out sequence.
Artifact model: Artifacts make users' conceptual distinctions clear. The artifact model is a drawing or photocopy of an artifact. Highlight structure with lines and labels; annotate location, record which parts support which intent; lightning bolts show where tool encumbers process or interferes with it. Look how content/represented information is related to artifact structure. Watch out for informal annotations. What about the format and presentation of the artifact makes it an appropriate carrier of the recorded information? What is accentuated, what is downplayed?
Cultural Model (107): A new system has to fit with customer's culture, otherwise it will be rejected – so pay attention to the cultural context of work. Factors include self-perception, formal and informal business policy, etc. Components of the model: Influencers as bubbles; Extent of effect of influencer on work shown by size of overlap of bubbles. Direction of influence or pushback as arrows. Typical important influencers: standards and policy, power, values, identity, emotion, team styles and preferences. How to recognize cultural factors: what is the tone of the environment? Is it elegant, messy, minimal? What is the role of policy? How is it recorded? What are motivations for sticking to it?
Physical Model (115): Physical environment creates design constraints. Environments are organized by workers to reflect the work they do. Model distinctions: places – show size, private or open, cluttered or empty, etc. Physical structures – large objects. Usage and movement within space. Hardware, software, communication lines, and tools. Artifacts and their locations; layout; breakdowns. Pay special attention to: walls – imaginary or real; how does space group people and functions? What is close at hand, what further removed, what inaccessible? The physical model is a drawing of the aspects of the environment that matter. Don’t just draw a floor plan or an inventory list.

Chapter 7: Structure of the Interpretation Session
Shared understanding – let every team member experience all interviews. A method to to communicate to others what you have learned in person. Each interviewer walks through each of their interviews for the team. Team listens, questions, draws work models, records issues, interpretations, design ideas. Ideally the team should be made up of ~4 people - how are we condensing this process down for our two-man team?

Part 3 - Chapter 8: Consolidation (139)
Goal: design for a population of users, but have your solution be flexible enough to fill inividual's specific needs. Segmenting by demographics is a poor substitute for segmenting by work practice patterns. If work practices are common, work models from individual interviews can be fused into a consolidated model. If they cannot be fused, then there is no single market and you need to design multiple solutions.

Chapter 9: Creating one view of the customer (151)
The chapter introduces two new tools: affinity diagrams and consolidated work models. The underlying thread is generalization from examples by induction. Never depend on theoretical arguments - reality often doesn't follow principles of deductive logic. Variations exist within a structure; consolidation makes that structure explicit. Explicit representations of work are needed - nearly all design thinking requires props - only externalized points of view can be used effectively by other team members.
The affinity diagram: hierarchical organization of interpretation session notes; group common themes and issues. Color coded: white-blue-pink-green. Build this after interviewing 15-20 customers with 50-100 notes per customer. Can be done in one day with on person per 100 notes. Ban familiar words to avoid stereotypical grouping - let grouping arise from the data. Put up a note and find others that go with it - no need to articulate relationship yet. "Two notes have an affinity if they are saying similar things about the work as it relates to the design focus of the team" - they are expressing a similar intent, problem, or issue in the user's work."(156) Groups are given their own labels - in customer's voice. The labels are the new info generated by the affinity map. Introduce all the new data at once to think broadly in different paradigms - drop by drop introduction leads to assimilation into existing thought models and results in small fixes instead of holistic redesign.
Consolidating Flow Models: find communication patterns and common roles in different jobs. Roles are collections of responsibilities. THey arise from the needs of the work and are thus often consistent across organizations. Roles are constant but mapping from people to roles changes across orgs. Split all responsibilities of an individual into coherent roles, then merge. Keep track of how roles are linked to observed individuals with another level of color coding. Step-by-step instructions for consolidation are on pg 169.

Bibtex entry:

@book{286067,
 author = {Hugh Beyer and Karen Holtzblatt},
 title = {Contextual design: defining customer-centered systems},
 year = {1998},
 isbn = {1-55680-411-1},
 publisher = {Morgan Kaufmann Publishers Inc.},
 }

Posted by Bjoern Hartmann at February 21, 2005 3:27 AM