Karen Holtzblatt

Karen Holtzblatt is the originator of Contextual Inquiry, a process for gathering fi eld data on product use, which was the precursor to Contextual Design, a complete method for the design of systems. Together with Hugh Beyer, the codeveloper of Contextual Design, Karen Holtzblatt is cofounder of InContext Enterprises, which specializes in process and product design consulting.

HS: What is Contextual Design? 

KH: If you’re going to build something that people want, there are basically three large steps that you have to go through. The fi rst question that you ask as a company is, “What in the world matters to the customer or user such that if we make something, they’re likely to buy it and use it?” So the question is “What matters?” Now once you identify what the issues are, every corporation will have the corporate response of how to change the human practice with technology to improve it. This is the ‘vision.’ Finally you have to work out the details and structure the vision into a product or system or website or handheld application . . . . In any design process, whether it’s formalized or not, every company must do these things. They have to fi nd out what matters, they have to vision their corporate response, and then they have to structure it into a system. Contextual Design has team and individual activities that bring them through those processes in an orderly fashion so that you can deliver a reliable result that works for people. So you could say that Contextual Design is a set of techniques to be used in a customer-centered design process with design teams. It is also a set of practices that help people engage in creative and productive design thinking with user data and it helps them co-operate and design together.

HS: What are the steps of Contextual Design? 

KH: In the ‘what matters’ piece, we go out into the fi eld, we talk with people about their work or life practice as they do it: that’s Contextual Inquiry and that’s a oneon-one, two to two-and-a-half-hour fi eld interview. Then we interpret that data with a cross-functional team, and we model the activities with fi ve work models: The fl ow model showing communication and coordination, the cultural model showing infl uences between people, both from law, and from geography, the physical model looking at the physical environment’s role in organizing activity, the sequence model showing the steps of a task or business process, and the artifact model showing the things people use and how they are used. We also capture individual points on virtual post-it notes. After the interpretation session, every person we interviewed has a set of models and a set of post-its. Our next step is to consolidate all that data because you don’t want to be designing from one person, from yourself, or from any one interview; we need to look at the structure of the practice itself. The consolidation step means that we end up with an affi nity diagram and fi ve consolidated models showing the issues across the target population. At that point, we have modeled the work practice as it is and we have now six communication devices that the team can dialog with. Each one of them poses a point of view on which to have the conversation ‘what matters?’ Now the team moves into that second activity, which is “what should our corporate response be?” We have a visioning process that is a very large group storytelling process to reinvent the practice given technological possibility and the core competency of the business. After that, we develop storyboards driven by the consolidated data and the vision. At this point we have not done a systems design; we have redesigned the practice. In Contextual Design we redesign the practice fi rst, seeing the technology as it will appear within the work or life activity that will change. To structure the system we start by rolling the storyboards into a User Environment Design (UED)—the structure of the system itself, independent of the user interface and the object model or implementation. The UED operates like a software fl oor plan that structures the movement inside the product. This is used to drive the user interface design, which is mocked up in paper and tested and iterated with the user. When it has stabilized, the UED, the storyboards, and the user interface drive development of the object model. Finally, we do visual design and mock the whole system up in an interactive environment and test that too. In this way we deal with interaction design, visual design and branding testing as well. This is the whole process of Contextual Design, a full front-end design process. Because it is done with a crossfunctional team, everyone in the organization knows what they’re doing at each point: they know how to select the data, they know how to work in groups to get all these different steps done. So not only do you end up with a set of design thinking techniques that help you to design, you have an organizational process that helps the organization actually do it.

HS: How did the idea of Contextual Design emerge? 

KH: Contextual Design started with the invention of Contextual Inquiry in a postdoctoral internship with John Whiteside at Digital in about 1987. At the time, usability testing and usability issues had been around maybe eight years or so and he was asking the question, “Usability identifi es about 10 to 20% of the fi xes at the tail end of the process to make the frosting on the cake look a little better to the user. What would it take to really fi gure out what people want in the product and system?” Contextual Inquiry was my answer to that question. After that, I took a job with Lou Cohen’s Quality group at DEC, where I picked up the affi nity diagram idea. Also at that time, Pelle Ehn and Kim Madsen were talking about Morten Kyng’s ideas on paper mock-ups and I added paper prototyping with post-its to check out the design. Sandy Jones and I worked out the lower level details of Contextual Inquiry then Hugh and I hooked up. He’s a software and object-oriented developer. We started working with teams and we noticed that they didn’t know how to go from the data to the design and they didn’t know how to structure the system to think about it. So then we invented more of the work models and the UED. So the Contextual Design method came from looking at the software development practice; we evolved every single step of this process based on what people needed. The whole process was worked out with real people doing real design in real companies. So, where did it come from? It came from dialog with the problem.

HS: What are the main problems that organizations face when putting Contextual Design into practice? 

KH: The question is, “What does organizational change look like?” because that’s what we’re talking about. The problem is that people want to change and they don’t want to change. What we communicate to people is that organizational change is piecemeal. In order to own a process you have to say what’s wrong with it, you have to change it a little bit, you have to say how whoever invented the process is wrong and how the people in the organization want to fi x it, you have to make it fi t with your organizational culture and issues. Most people will adopt the fi eld-data gathering fi rst and that’s all they’ll do and they’ll tell me that they don’t have time for anything else and they don’t need anything else, and that’s fi ne. And then they’ll wake up one day and they’ll say, “We have all this qualitative stuff and nobody’s using it . . . maybe we should have a debriefi ng session.” So then they have debriefi ng sessions. Then they wake up later on and they say, “We don’t have any way of structuring this information . . . models are a good idea.” And basically they reconstruct many aspects of the Contextual Design process as they hit the next problem—of course adding their own fl avor and twists and things they learned along the way. Now it’s not quite that clean, but my point is that organizational adoption is about people making it their own and taking on the parts, changing them, doing what they can. You have to get somebody to do something and then once they do something it snowballs. From an organization change perspective it is nice that Contextual Design generates paper and a design room as part of the process. The design room creates a talk event, and the talk event pulls everyone in because they want to know what you’re doing. Then if they like the data, others feel left out, and because they feel left out they want to do a project and they want to have a room for themselves as well. The biggest complaint about Contextual Design is that it takes too long. Some of that is about time, some of it is about thought. You have people who are used to coding and now have to think about fi eld data. They’re not used to that. So for that reason we wrote Rapid CD—to help people see how to pick and choose techniques from Contextual Design in short amounts of time.

HS: You have recently published a book on Rapid CD. What are the compromises that you made when integrating Contextual Design into a shortened product lifecycle? 

KH: The most important thing to understand about Contextual Design and in point of fact any user-centred design approach is that time is completely dependent on scope. The second factor, which is actually secondary to scope, is the number of models that you use to represent the data.  Rapid CD creates guidelines to help you identify a small enough scope so that you can get user data into projects quickly. If you have a small tight scope then it’s going to take less time because you’re going to interview fewer users, and you’re going to have a less extensive design. Limiting your product or system to one to four job types means that your scope is going to be small, and then after the visioning process you can prioritize scope again. At that point you may end up prioritising out roles and aspects of the vision that can be addressed later. The next phase of Rapid CD is working out the details of the design through paper prototyping and visual design and so on. This phase is again completely dependent on scope. If we already started with one to four roles, you’re not going to have more than that so you can keep the number of screens to be developed small enough to manage quickly. The difference between this process and a normal Contextual Design process is that you are limiting scope and as a result you can do it with fewer people and in less time. The second thing that we do in Rapid CD is we limit the number of models. One thing that we cut out is the UED. We eliminate the UED because we’ve limited the scope and if we’re doing something simple like a webpage where you already have the idea of a webmap (which is effectively a UED), or you’re doing the next version of a particular product which means you already have system structure, then you can go from having the data and the vision to mocking up some user interfaces. So we eliminate the UED without feeling that we’re losing quality because we’ve reduced scope. One model we don’t cut out at all is the affi nity diagram because it’s the best organisation and structure for understanding the issues. Finally, depending on the problem and how Contextual Design is being used we may or may not have sequence models (task analysis) as part of Rapid CD. To make it easy for people we characterised Rapid CD into three smaller processes: Lightning Fast, Lightning Fast Plus, and Focused Rapid CD. With Lightning Fast you use Contextual Design up to the end of the visioning process and then follow your normal process to work out the detailed design. It appears shorter because we’re just using Contextual Design for the requirements gathering phase and to conceptualise the product or process. In Lightning Fast Plus you do the visioning process and work up your ideas your way, then you mock up your interfaces, and take them out and test them with users. Any time you’re not testing with the user you’re at risk. So in Lightning Fast Plus we’re skipping storyboarding, extensive modeling, and the UED. In Focused Rapid CD you do sequence consolidation for a task analysis, vision a solution, then storyboarding, paper mockups, and testing. So Focused Rapid CD eliminates the UED and the rest of the models. Focused Rapid CD says if you have a task or a small process then you really need to do consolidated sequences, in other words, you need to do task analysis. In typical webpage design you don’t need sequences unless you’re doing transactions. If all you’re doing is an information environment, you don’t need sequences. But any time you need to do task analysis then the recommendation would be that you use Focused Rapid CD.

HS: What’s the future direction of Contextual Design? 

KH: Every process can always be tweaked. I think the primary parts of Contextual Design are there. There are interesting directions in which it can go, but there’s only so much we can get our audience to buy. I think that for us there are two key things that we’re doing. One is we’re starting to talk about design and what design is, so we can talk about the role of design and design thinking. And we are still helping train everyone who wants to learn. But the other thing we’re fi nding is that sometimes the best way to support the client is to do the design work for them. So we have the design wing of the business where we put together the Contextual Design teams. What clients really like is our hybrid design process where we create a cross company team and do the work together—they learn and we get the result. A new challenge for Contextual Design is its role in Six Sigma process redefi nition work. We believe that qualitative approaches to business process redesign works well with quantitative approaches like Six Sigma. Our initial work on this has shown that Contextual Design uncovers root causes and processes to address much much faster than typical process mapping. And our visioning process helps redesign process and technology together—so that they inform each other instead of trying to deal with one at a time. We hope to have more stories about these successes in the future. But for most organizations looking to adopt a customer-centered design process, the standard Contextual Design is enough for now, they have to get started. And because Contextual Design is a scaffolding, they can plug other processes into it, as we suggest with Rapid CD. Most organizations haven’t got a backbone for customer-centered design, and Contextual Design is a good backbone to start with. ■