Contextual Design is a structured, well-defined user-centered design process that provides methods to collect data about users in the field, interpret and consolidate that data in a structured way, use the data to create and prototype product and service concepts, and iteratively test and refine those concepts with users. This is the core of the Contextual Design philosophy - understand users in order to find out their fundamental intents, desires, and drivers. But these are invisible to the users - so the only way to glean them is to go out in the field and talk with people
Although based on theories from several disciplines, including anthropology, psychology and design, Contextual Design was designed for practical application with commercial design teams.
Since its original development, Contextual Design has been applied in a variety of industries and also used as a vehicle to teach user-centered design principles in engineering and design programs.
Contextual Design has primarily been used for the design of computer information and IT systems, including hardware (Curtis et al 1999) and software (Rockwell 1999). Parts of Contextual Design have been adapted for use as a field usability evaluation method (McDonald et al 2006). Contextual Design has also been applied to the design of digital libraries and other learning technologies (Notess 2005, Notess 2004). Contextual Design has also been used in a variety of other industries, including web applications, process reengineering, consumer product design, manufacturing, and automotive and medical device design, to name just a few.
Contextual design has also been widely used as a means of teaching user-centered design and human-computer interaction at the university level (Weinberg and Stephen 2002, Larusdottir 2006).
8.1 Motivations and Key Principles
A small number of key principles shaped the development of Contextual Design and provide the key motivations for its use as a design tool.
8.1.1 Principle: System design must support and extend users' work practice
Contextual Design is rooted in the observation that any technology or system is always situated in a larger environmental context - and that introduction of new solutions invariably changes the environment for its users. In Contextual Design, the term work practice refers to the complex and detailed set of behaviors, attitudes, goals and intents that characterize a set of users in a particular environment. All manner of activities and design domains are characterized by work practice - not only workplaces. For example, there are obviously work practices associated with business pursuits like office work, but there are also "work practices" associated with life events such as making purchases as a consumer, driving an automobile, playing music and even watching television. A central tenet of Contextual Design is that any technology, product or system must be designed to support and extend its users' work practice . If it does so well, it will be accepted and valued; if it fails to do so, it will cause dissatisfaction, frustration, avoidance and workarounds
Implications for the designer: To create a successful product, first be aware of users' work practice and design for it explicitly.
8.1.2 Principle: People are experts at what they do - but are unable to articulate their own work practice
Complicating the designer's job are two facts about work practice. The first is that people are not consciously aware of their own work practice; all of their knowledge is tacit. This is especially true when people are taken out of the context of their everyday environment. It is only when users are immersed in normal contexts of use that they can become aware of their own work practice - what they do in detail and why. They become "aware in the doing," as Michael Polanyi puts it (Polanyi 1958).
The second is that work practice is complex and varied, and that useful design data are hidden in everyday details. Many systems fall short of expectations because they fail to take into considerations seemingly insignificant details of work practice - details that are not consciously available to users when they are not engaged in the ongoing work.
Contextual Design holds that design team members must go into the field and observe and talk with users in their natural work or life environments - their natural contexts - in order to understand work practice. This is the principle of context from which the process draws its name. This aspect of Contextual Design leverages the work of earlier ethnographic methodologies (Garfinkel 1967) but extends it in important ways.
Implications for the designer: Use field interviews to reveal tacit aspects of users' work practice - the motivations, workarounds, and strategies that they may never articulate, but structure their work.
8.1.3 Principle: Good design requires partnership and participation with users
Even while in context, users are not always able to intuit and articulate their own behaviors and detailed motivations. And so Contextual Design prescribes interviews that are not pure ethnographic observations, but involve the user in discussion and reflection on their own actions, intents, and values.
The interviewer actively questions the user and partners with them to draw out and understand their work practice in detail. The interviewer thus does not enter with a preformed list of questions, as in a survey or focus group, but rather adopts a master-apprentice relationship model , seeking to understand the user's work as an apprentice would from a master, as the work is ongoing.
This key concept of partnership also comes into play in Contextual Design's use of paper prototypes and short iterations with users to work out detailed design. The thinking behind Contextual Design's iterative prototyping evolved in conjunction with, and influenced, the development of participatory design techniques in the 1980's and 1990's (Schuler and Namioka 1993).
Implications for the designer: Don't just observe when you're in the field. Ask questions and suggest interpretations of the user's actions and motivations. Articulate what matters about the work together.
8.1.4 Principle: Good design is systemic
Any good design considers the system and its impact on users as a whole: the handles on a Mini Cooper reflect the aesthetic of the entire car; the iPhone's characteristic user interface elements (including gestures) are carried through the entire design and the apps; all parts of the amazon.com site support the focus on user interests, community ratings, related material, and easy purchase. And all pages of the site look like they are part of the site - a single page could not be changed
Contextual Design provides methods that help a team keep the design coherent. The Contextual Design vision provides a high-level coherent direction; the storyboards provide coherence of task; the User Environment Design ensures structural coherence across the system. All these methods - which are explained in the following section - encourage the designer to think about the entire system, rather than treating each part as its own independent problem to be solved. This provides users with a seamless
Implications for the designer: Use concrete representations to maintain system coherence: function, structure, layout, and flow across the system.
8.1.5 Principle: Design depends on explicit representations
When people design, they create physical representations of their concepts. Whether written on the back of a napkin or captured in a high-end modeling tool, designers need a tangible representation of their thoughts. From sketches to formal diagrams, drawings enable designers to work out their ideas, capture their thinking, share it with others, discuss it, and identify weaknesses.
Contextual Design supports this need for a physical representation throughout the design process. Work models make work practice - how users approach their work - explicit, public, and sharable. The User Environment Design shows the structure of the system as experienced by the user. Each technique in Contextual Design has its own tangible representation that supports doing the work, capturing the result, and sharing it with others. These physical representations in Contextual Design are described in the next section.
Implications for the designer: Use drawings, sketches and models to capture key design considerations at every step of the process.
8.2 Description of the Contextual Design Process
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.1: The Contextual Design Process
Contextual Design is broadly divided into two major phases (see Figure 1). In the following section we'll describe the initial parts of the process, from Contextual Inquiry through visioning. These initial parts are aimed at creating a structured representation of the users' work practice that is actionable for design. Later we'll describe the second phase in the process, which is aimed at working out the details of the design concepts developed in the first half of the process by way of iterative prototyping with users.
8.2.1 Contextual Inquiry
The first problem for design is to understand the customers: the people who will use the solution directly (end-users); those who provide them information or use their output (indirect users); those who manage them and are responsible for their success (managers); those who purchase the product and may have their own, quite independent, criteria. For most projects, the main focus is nearly always on the end-users, but it is important to consider and evaluate the needs of the other types of customers as well.
Contextual inquiry is an explicit step for understanding who the customers really are and how they work on a day-to-day basis. The difficulty is that, as we described above, work becomes so habitual to end-users that they often have difficulty articulating exactly what they do and why they do it. So the design team conducts one-on-one field interviews with users in their workplace to discover what matters in the work. These are not traditional question and answer interviews. Instead, a contextual interviewer observes users as they work and inquires into the users' actions as they unfold to understand their motivations and strategy. The interviewer and user, through discussion, develop a shared interpretation of the work. It is like an active inquiry into the user's world. This inquiry, done in context, is where Contextual Inquiry gets its name.
Team interpretation sessions bring a cross-functional design team together to hear the whole story of an interview and capture the insights and learning relevant to their design problem. An interpretation session lets everyone on the team bring their unique perspective to the data, sharing design, marketing, and business implications. Through these discussions, the team comes to understand the customer whose data is being interpreted and their needs, while at the same time capturing issues, drawing work models, and developing a shared understanding of the customer's world.
8.2.2 Work Modeling
As described earlier, people's work is complex and full of detail. It's also intangible - there has traditionally been no good way to write down or talk about work practice. Design teams seldom have the critical skill of seeing the structure of work done by others, looking past the surface detail to see the intents, strategies, and motivations that control how work is done - and typical development methodologies do little to encourage this perspective.
Because this is immensely important, so in Contextual Design, work models are used to capture the work of individuals and organizations in diagrams. Five different models provide five perspectives on how work is done:
The flow model captures communication and coordination between people to accomplish work. It reveals the formal and informal workgroups and communication patterns critical to doing the work. It shows how work is divided into formal and informal roles and responsibilities.
The cultural model captures culture and policy that constrain how work is done. It shows how people are constrained and how they work around those constraints to make sure the work is done.
The sequence model shows the detailed steps performed to accomplish each task important to the work. It shows the different strategies people use, the intents or goals that their task steps are trying to accomplish, and the problems getting in their way.
The physical model shows the physical environment as it supports or gets in the way of the work. It shows how people organize their environments to make their work easier.
The artifact model shows the artifacts that are created and used in doing the work. Artifacts reveal how people think about their work - the concepts they use and how they organize them to get the work done.
Author/Copyright holder: Unknown (pending investigation) Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.2: The Flow Model captures communication and coordination between people to accomplish work. It reveals the formal and informal workgroups and communication patterns critical to doing the work. It shows how work is divided into formal and informal roles and responsibilities.
Author/Copyright holder: Unknown (pending investigation) Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.3: The Cultural Model captures culture and policy that constrain how work is done. It shows how people are constrained and how they work around those constraints to make sure the work is done.
Author/Copyright holder: Unknown (pending investigation) Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.4: The Sequence Model shows the detailed steps performed to accomplish each task important to the work. It shows the different strategies people use, the intents or goals that their task steps are trying to accomplish, and the problems getting in their way.
Author/Copyright holder: Unknown (pending investigation) Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.5: The Physical Model shows the physical environment as it supports or gets in the way of the work. It shows how people organize their environments to make their work easier.
Author/Copyright holder: Unknown (pending investigation) Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.6: The Artifact Model shows the artifacts that are created and used in doing the work. Artifacts reveal how people think about their work - the concepts they use and how they organize them to get the work done.
8.2.3 Consolidation
Systems are seldom designed for a single customer. But designing for a whole customer population - the market, department, or organization that will use the system - depends on seeing the common aspects of the work different people do.
Consolidation brings data from individual customer interviews together so the team can see common pattern and structure without losing individual variation. The affinity diagram brings together issues and insights across all customers into a wall-sized, hierarchical diagram to reveal the scope of the problem.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.7: Portion of an Affinity Diagram. The affinity diagram brings together issues and insights across all customers into a wall-sized, hierarchical diagram to reveal the scope of the problem and the opportunities.
Consolidated work models bring together each different type of work model separately, to reveal common strategies and intents while retaining and organizing individual differences. Together, the affinity diagram and consolidated work models produce a single picture of the customer population a design will address. They give the team a focus for the design conversation, showing how the work hangs together rather than breaking it up in lists. They show what matters in the work and guide the structuring of a coherent response, including system focus and features, business actions, and delivery mechanisms.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.8: Consolidated Flow Model
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.9: Consolidated Cultural Model
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.10: Portion of Consolidated Sequence Model
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.11: Consolidated Physical Model
Author/Copyright holder: Courtesy of Sourasith Simonphone. Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.12: Consolidated Artifact Model
8.2.4 Personas built with contextual data
Personas can help bring users alive and focus the stakeholders on the relevant issues, if they are built from rich contextual data. Popularized by Alan Cooper, a persona describes typical users of the proposed system as though they were real people (Cooper 1998). Their use is becoming more widespread, though with mixed success. According to Harley Manning's research, "a persona that's not backed by rich contextual data isn't valid, which accounts for much of the mixed success." (Manning 2003)
Contextual Design calls for building personas from the field data the team collected and consolidated to help focus on the characters the design team will vision about in the next step, to help stakeholders segment their market according to practice instead of typical demographics, to clarify branding and prioritization, and to bring the users and their needs to life for developers. Contextual Design personas are built from the detailed data gathered through Contextual Inquiry interviews, so they have the richness and depth needed to drive design.
8.2.5 The Design Response: Visioning
Up to this point, a Contextual Design project focuses on understanding the users as they are. Now a team must invent the design solution using technology to transform the tasks, and possibly also designing new business processes to streamline tasks or new services to support the market. A Contextual Design team invents these solutions through visioning.
In visioning, the team uses the consolidated data to drive conversations about how to improve users' work by using technology to transform the work practice. This focuses the conversation on how to improve people's lives with technology, rather than on what could be done with technology without considering the impact on peoples' real lives.
The vision captures a story of how customers will do their work in the new world the team invents. A vision includes the system, its delivery, and support structures to make the new work practice successful. It is intentionally rough and high-level - a vision sets a possible design direction, without fleshing out every detail. This enables the team to see the overall structure of the solution and ensure its coherence.
Author/Copyright holder: Courtesy of Sourasith Simonphone. Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.13: The Vision captures a story of how customers will do their work in the new world the team invents. A vision includes the system, its delivery, and support structures to make the new work practice successful
8.2.6 Storyboards
The vision defines the high-level design response to users' needs. To become actionable, the team must define the detailed function, behavior, and structure of the proposed system. This next level of design must take the users' tasks into account and ensure the right function is defined in the right system places for a smooth workflow. As you'll see in the following section, Contextual Design provides for this structural design through storyboards and the User Environment Design, and then validates the design through paper prototypes.
Each storyboard describes how users will accomplish a task in the new system. They show the steps the user will take and the system function that supports each step. The task may be handed off between users, and may be supported by several systems operating together; the storyboard ensures the task remains coherent across these boundaries.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.14: Portion of a Storyboard. A storyboard is represented as a sequence of "freeze-frame" sketches or cells, each one capturing one step in the overall task
8.2.7 User Environment Design
The storyboards ensure coherence of individual tasks, but the new system must have the appropriate structure to support a natural flow of work through the system no matter what task the user is doing. Just as architects draw floor plans to see the structure and flow of a house, designers need to see the "floor plan" of their new system - the basic structure that will be revealed by the user interface drawing, implemented by an object model, and that responds to the customer work. This "floor plan" is typically not made explicit in the design process.
The User Environment Design captures the floor plan of the new system. It shows each part of the system, how it supports the user's work, exactly what function is available in that part, and how the user gets to and from other parts of the system - without tying this structure to any particular user interface.
With an explicit User Environment Design, a team can make sure the structure is right for the user, plan how to roll out new features in a series of releases, and manage the work of the project across engineering teams at a level of abstraction that is above screens and dialogs. Using a diagram which focuses on keeping the system coherent for the user counterbalances other forces that would sacrifice coherence for ease of implementation or delivery.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.15: Portion of a User Environment Design. The User Environment Design shows each part of the system, how it supports the user's work, exactly what function is available in that part, and how the user gets to and from other parts of the system - without tying this structure to any particular user interface.
8.2.8 Paper prototyping
Testing is an important part of any system development. It's generally accepted that the sooner problems are found, the less it costs to fix them. So it's important to test and iterate a design early, before anyone gets invested in the design and before spending time writing code. And the simpler a testing process is, the more time is available for multiple iterations to work out the detailed design with users.
Paper prototyping develops rough mockups of the system using notes and hand drawn paper to represent windows, dialog boxes, buttons, and menus. The use of paper prototypes is described in many resources, including Carolyn Snyder's book on the subject (Snyder 2003). The design team tests these prototypes with users in their workplace, replaying real work events in the proposed system. When the user discovers problems, they and the designers redesign the prototype together to fit their needs. Rough paper prototypes of the system design test the structure of a User Environment Design and initial user interface ideas before anything is committed to code. Paper prototypes support iteration of the new system, keeping it true to the user needs. Refining the design with users gives designers a customer-centered way to resolve disagreements and work out the next layer of requirements. After several rounds of prototyping, the larger structure of the system design stabilizes. At this point, the design team can continue iterating areas of the user interface.
Once the structure and interaction design are largely stable, the team can develop and test interaction and visual design options with users.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 8.16: Portion of a Paper Prototype. Paper prototyping develops rough mockups of the system using notes and hand drawn paper to represent windows, dialog boxes, buttons, menus, and the other user interface elements the customer will use.
8.2.9 Driving Product Development
Companies implement a variety of hardware and software development methodologies within which their front-end design process, whether user-centered or not, must fit. Most methodologies define a series of stages, each with deliverables and milestones. Few define specific ways of gathering requirements, instead leaving the specific method open to definition by the product team. Contextual Design is usually included in the requirements gathering step or very early pre-commitment stage gates of these methodologies.
The translation from any kind of research on user needs to design requirements often lacks process and rigor. The structure that Contextual Design offers design teams helps bring some amount of control to this activity. The User Environment Design captures the required function and behavior of the new system, at least for the core work cases. The paper prototypes capture the proposed user interface, though usually only at a rough, wireframe level. These can be harvested to provide the Product Requirements Document and User Interface Specification.
8.2.10 Contextual Design and Agile Development
Currently, many organizations are moving to Agile development. In contrast to traditional approaches that emphasize requirements analysis, design, and implementation as distinct phases, Agile methods seek to minimize up-front planning in favor of producing working base levels quickly and often. Feedback from these base levels is used to ensure that the resulting product is useful. Scrum (Schwaber and Beedle 2001) and XP (Beck 2004) (Extreme Programming) are two popular Agile approaches.
Agile development dovetails very nicely with user-centered design (Beyer 2010). But, Agile teams often struggle to include a reliable customer voice, something Agile methods assume they can do. Attempts to substitute stakeholders or internal product owners for the real end-user have only shown how critical that user voice is. Contextual Design provides proven techniques for collecting and using user knowledge which can be adopted by Agile teams.
Before Agile development begins, the initial stages of Contextual Design provide the team with the knowledge they need to write viable user stories. Contextual Inquiry interviews, the affinity diagram, and work models provide the deep understanding of the user needed by the team. Visioning sets the project direction and defines what kind of solution to provide. And storyboards, the User Environment Design, and paper prototypes develop and validate the right function to be included in user stories for Agile release planning. This is critical - paper prototype iterations ensure the team is developing the right design, that it is solving real user problems. It's cheaper and faster to refine the design at this point than in the middle of development iterations.
The key difference between supporting an Agile team and traditional waterfall development is that for an Agile project, the above steps are all that need be done. No writing functional specifications, user interface specifications, or architectures. The User Environment Design is kept at the level required for the team to keep its own thinking clear - it is not intended as a communication mechanism to the development team.
Instead, the User Environment Design and paper prototypes are used as the source for writing user stories in the release planning session. They provide enough detail to make it easy to write and estimate stories. Iterations can be planned so each iteration collects stories that, taken together, deliver coherent user value - as defined by the User Environment Design.
During Agile development proper, the techniques of Contextual Design continue to provide critical support to the team. Knowledge gained from field research gives the team confidence in their prioritization of user stories. The detailed user interface can be defined during iterations, usually one iteration ahead of development work. Contextual Inquiry field visits allow detailed user interface designs to be iterated with users. Completed base levels can also be tested using Contextual Inquiry techniques, and the results used to refine the direction of the project.
8.3 Background and History of Contextual Design
Karen Holtzblatt and Hugh Beyer first developed the key parts of the Contextual Design process while working at Digital Equipment Corporation (DEC) in the early 1980s. Karen, a psychologist by training, and Hugh, a developer, recognized the need for a coherent and structured design process that could integrate useful practices from their respective fields, and make it all accessible and actionable to design teams in commercial settings.
Holtzblatt's initial work was a response to the limitations of usability testing and human factors work as it existed in the early 1980's. Whiteside, Bennett, and Holtzblatt (Whiteside et al 1988) introduced and discussed the theoretical foundation for using ethnographic and hermeneutic techniques to understand user practice for the purpose of systems design. At the time, usability methods were focused on lab-based quantitative measures, but these techniques are always limited in the amount of impact they can have and do not lead to wholly new insights and design directions.
Holtzblatt brought techniques from psychology and sociology to the field, showing how the kind of verbal protocol analysis used by Ericsson (Ericsson and Simon 1984) and Piaget (Piaget 1960) could be applied to data collected from users in the field. This data forms the bases for a grounded theory, as defined by Glaser and Strauss (Glaser and Strauss 1967), and as such motivates design action. Contextual inquiry was defined as a structured method for gathering and using field data using this theoretical foundation.
The resulting techniques are similar in nature to an ethnographic study. However, contextual inquiry is constrained by the limitations of an engineering project. So field interviews are restricted to a few hours, not days or weeks, and the interaction between interviewer and user is defined as a focused conversation. The purpose of the conversation is to reveal and articulate the nature of the user's work practice, and this purpose is understood and shared by both participants.
At the same time, Holtzblatt was adapting physical mockup techniques developed by Kyng, Ehn and others (Kyng 1988; Ehn 1988) to software. In Denmark, Scandinavian countries mandated that labor representatives be included in any redesign of the workplace by creating mockups of rooms and workstations using large cardboard boxes and other simple, physical representations. Sessions were conducted with the workers in which they ran through typical tasks in his simulated environment, redesigning it to work better as they discovered problems.
Holtzblatt scaled down this method for software, using hand-drawn user interfaces on sticky notes to represent a proposed design and working through the user's own tasks, in their own workplaces, to explore the usefulness of the design. Together, designer and user would modify the prototype in the moment to eliminate problems and add needed function.
Work models were developed by Holtzblatt as a way to capture the discussion in design teams about user work practice - as a way to make elements of work practice explicit to all members of the team. The User Environment Design, similarly, was developed to capture the system structure and function without sidetracking the discussion with user interface details prematurely.
The resulting Contextual Design process was first used at DEC and later gained acceptance in the rapidly growing Human Computer Interaction (HCI) community throughout the 1980's, following the same heretic-to-accepted-practice trajectory that the HCI field itself was undergoing (Caroll 2009). Following a series of articles on various aspects of Contextual Design in the HCI literature (e.g. (Beyer and Holtzblatt 1993), (Holtzblatt and Jones 1993)), the entire process was described in the 1997 text Contextual Design (Beyer and Holtzblatt 1997). In 2005, the follow-up handbook Rapid Contextual Design (Holtzblatt et al 2005) expanded upon the method and provided more practical guidance. It also addressed an oft-heard criticism that the Contextual Design method could be too labor-intensive or lengthy for some projects.
8.4 Future Directions
The core elements of Contextual Design have been stable for over a decade and are unlikely to change fundamentally in the future. However, the context in which Contextual Design is used does change and that is likely to drive changes in how the process is used. Here are some possible directions to keep an eye on.
Agile development. As Agile processes become more widespread and more accepted, the relationship between Agile development and user-centered processes can be expected to evolve. Agile development itself is strengthened by robust user-centered techniques, but the integration of a coherent design focus with Agile development is still not well-accepted. And the introduction of new Agile methods such as Kanban will continue to provide challenges to good User Experience design.
Quantitative techniques. Ideally, the qualitative data provided by contextual inquiry would be augmented with quantitative data provided through research methods such as surveys. When making a business case, it is important to know not just what users want, but how many potential customers there are and what they are willing to pay for a solution to their problem. Contextual Design can and should be integrated into a whole product concepting and initiation process.
Enterprise-scale projects. For large-scale projects, enterprises have to coordinate multiple work streams and hundreds of people over years to accomplish the business goal. Contextual Design can play a key role in identifying the most important problems to solve, prioritizing the rollout of the solution, maintaining coherence of the system vision, and ensuring that as parts are rolled out iteratively the inevitable engineering tradeoffs do not degrade the usability of the system.
8.5 Where to Learn More
The definitive sources on Contextual Design are:
Holtzblatt, Karen and Beyer, Hugh. Contextual Design: Defining Customer-Centered Systems. San Francisco : Morgan Kaufman Publishers, 1997.
Holtzblatt, Karen, Wendell, Jessamyn and Wood, Shelley. Rapid Contextual Design: A How-to Guide to Key Technologies for User-Centered Design. San Francisco : Morgan Kaufman Publishers, 2005.
Beyer, Hugh. Contextual Design for Agile Teams. Morgan Claypool. San Rafael, CA. 2010.
Papers and case studies describing uses of Contextual Design abound in the literature. Some have been referenced below, others can be found on the InContext website at: http://www.incontextdesign.com.
8.6 References
Proceedings of the 33rd SIGCSE technical symposium on Computer science education 2002.
JCDL05 Proceedings of the 5th ACM/IEEE-CS Joint Conference on Digital Libraries 2005.
Armstrong, Anne-Marie (2004): Instructional Design in the Real World: A View from the Trenches. Idea Group Publishers
Beck, Kent (2004): Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional
Beck, Kent (1999): Extreme Programming Explained: Embrace Change. Reading, MA, Addison-Wesley Publishing
Beyer, Hugh R. (2010a): Contextual Design for Agile Teams. Morgan Claypool
Beyer, Hugh R. (2010b): User-Centered Agile Methods. Morgan and Claypool Publishers
Beyer, Hugh and Holtzblatt, Karen (1998): Contextual design: defining customer-centered systems. San Francisco, Elsevier
Beyer, Hugh R. and Holtzblatt, Karen (1997): Contextual Design: Defining Customer-Centered Systems (Interactive Technologies). Morgan Kaufmann
Beyer, Hugh R. and Holtzblatt, Karen (1993): Contextual Design: Toward a Customer-Centered Development Process. In: Software Development 93 Spring Proceedings February, 1993, Santa Clara, CA, USA.
Beyer, Hugh R. and Holtzblatt, Karen (1995): Apprenticing with the Customer. In Communications of the ACM, 38 (5) pp. 45-52
Carroll, John M. (2013). Human Computer Interaction - brief intro. Retrieved 4 November 2013 from [URL to be defined - in press]
Cooper, Alan (1998): The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Sams Publishing
Cooper, Alan (1999): The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Sams
Curtis, Paula, Heiserman, Tammy, Jobusch, David, Notess, Mark and Webb, Jayson (1999): Customer-Focused Design Data in a Large, Multi-Site Organization. In: Altom, Mark W. and Williams, Marian G. (eds.) Proceedings of the ACM CHI 99 Human Factors in Computing Systems Conference May 15-20, 1999, Pittsburgh, Pennsylvania. pp. 608-615
Ehn, Pelle (1988): Work-Oriented Design of Computer Artifacts. Stockholm, Arbetslivscentrum
Ericsson, K. A. and Simon, Herbert A. (1984): Protocol Analysis: Verbal Reports as Data. Cambridge, MA, MIT Press
Garfinkel, Harold (1967): Studies in Ethnomethodology. London, United Kingdom, Polity Press
Glaser, Barney and Strauss, Anselm (1967): The Discovery of Grounded Theory: Strategies for Qualitative Research.Aldine Transaction
Holtzblatt, Karen and Beyer, Hugh R. (1993): Making Customer-Centered Design Work for Teams. InCommunications of the ACM, 36 (10) pp. 92-103
Holtzblatt, Karen and Jones, Sandra (1993): Contextual Inquiry: A Participatory Technique for System Design. In:Namioka, Aki and Schuler, Doug (eds.). "Participatory Design: Principles and Practice". Hillsdale, NJ, USA: Lawrence Earlbaumpp. 177-210
Holtzblatt, Karen, Wendell, Jessamyn Burns and Wood, Shelley (2004): Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design (Interactive Technologies). Morgan Kaufmann
Kyng, Morten (1988): Designing for a Dollar a Day. In: Greif, Irene (ed.) Proceedings of the 1988 ACM conference on Computer-supported cooperative work September 26 - 28, 1988, Portland, Oregon, United States. pp. 178-188
Lárusdóttir, M. K. "Using Rapid Contextual Design at Reykjavik University", accepted paper for the workshop named "HCIEd.2006-1 inventivity: Teaching theory, design and innovation in HCI" held by British Computer Society HCI Group (BHCIG), the International Federation of Information Processing (IFIP) WG13.1 Education, and the Irish Computer Society" in Limrick in Ireland, 23rd – 24th March, 2006
Manning, Harley (2003). The Power Of Design Personas. Retrieved [Date unavailable] from Forrester Research: http://www.forrester.com/ER/Research/Report/Summar...
Mcdonald, Sharon, Monahan, Kelly and Cockton, Gilbert (2006): Modified contextual design as a field evaluation method. In: Proceedings of the Fourth Nordic Conference on Human-Computer Interaction 2006. pp. 437-440
Notess, Mark (2005): Using Contextual Design for Digital Library Field Studies. In: JCDL05 Proceedings of the 5th ACM/IEEE-CS Joint Conference on Digital Libraries 2005.
Notess, Mark (2004): Applying Contextual Design to Educational Software Development. In: Armstrong, Anne-Marie (ed.). "Instructional Design in the Real World: A View from the Trenches (Advanced Topics in Information Resources Management)". Idea Group Publishers
Piaget, Jean (1960): The Child's Conception of the World. Rowman and Littlefield Publishers, Inc
Polanyi, Michael (1958): Personal Knowledge: towards a post-critical philosophy. London, Routledge
Rockwell, Chris (1999): Customer connection creates a winning product: building success with contextual techniques. In Interactions, 6 (1) pp. 50-57
Schuler, Douglas and Namioka, Aki (eds.) (1993): Participatory Design: Principles and Practices. Hillsdale, NJ, USA, Lawrence Erlbaum Associates
Schwaber, Ken and Beedle, Mike (2001): Agile Software Development with Scrum. Prentice Hall
Snyder, Carolyn (2003): Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann
Weinberg, Jerry B. and Stephen, Mary L. (2002): Participatory design in a human-computer interaction course: teaching ethnography methods to computer scientists. In: Proceedings of the 33rd SIGCSE technical symposium on Computer science education 2002. pp. 237-241
Whiteside, John, Bennett, John and Holtzblatt, Karen (1988): Usability Engineering: Our Experience and Evolution. In: Helander, Martin and Landauer, Thomas K. (eds.). "Handbook of Human Computer Interaction". North Holland
