The X-Interviews | Design in Perspective
Interview #2 - Karen Holtzblatt on Contextual Design
Karen Holtzblatt on Contextual Design
While working with the Microsoft Business Intelligence Group in the early 2000s, our leadership team was asking a fundamental question: “What should we build?” Engineers had already started coding the underlying architecture for a massive Corporate Performance Management system. Yet, we didn’t have agreement on what experiences we needed to deliver to the end users of the system. We needed to figure out the right product to produce, so that it would not just sell, but also delight customers. I had recently attended a CHI Conference, where I met Karen Holtzblatt and participated in one of her workshops on Contextual Design. It seemed clear to me that what our team needed was exactly what Contextual Design offered: cross-functional buy-in based on the needs of the customer and the needs of the business.
Thanks for reading The X-Mentor! Subscribe for free to receive new posts and support my work.
X-Mentor: Hi Karen. Good to have you with us today! By way of introduction, I would like to let our readers know that we have a very special guest on The X-Mentor. Karen Holtzblatt is an American computer scientist and experience design pioneer that is known for her contributions to HCI, that’s Human Computer Interaction, and particularly in Contextual Design. She founded InContext Design in 1992 with Hugh Beyer and is its CEO. Karen was elected to the CHI Academy in 2007 and won the first ACM SIGCHI Lifetime Award for Practice in 2010. For the past 10 years, Karen has been working on issues of retaining women in Tech. Her latest book with Nicola Marsden is Retaining Women in Tech: Shifting the Paradigm published under Springer. An important topic and I encourage readers to check out.
Welcome to The X-Mentor, Karen!
What is Contextual Design?
X-Mentor: Karen, let’s dive right in. You are known the world over for your work in Contextual Design. So, I wanted to start there so that our readers can understand the impact it’s had over the years.
X-Mentor: You have devoted a career, a lifetime practically, to mentoring other people in Contextual Design, myself included along with many, if not most, of my colleagues. You’ve spent a considerable amount of time teaching people how to apply Contextual Design, both through your consulting and also at global conferences like CHI. And you’ve published multiple books on the subject. But for those readers that may not be familiar with Contextual Design, or what you’ve done to help establish, advance, and contribute to our discipline, can you tell us about Contextual Design? What is it?
Karen: Well to start, as we’ve been thinking about doing this talk, I wanted to address the word “design.” Because, of course, we call our process Contextual Design. I think over the years, we’re talking about 35, 40 years now. When I started doing this work there was no field. There were no designers as we understand them today. There were no user researchers, there was only tail-end usability testing. The field of HCI was just coming to be, and there were only engineers. And let’s be very clear, they were pretty much all men. This is where the industry was when we started, and yet we called it Contextual Design. When I was at Digital Equipment Corporation (my first job), the products were green screens and typing things into command lines and forms. Design as we know it today—meaning layout, interaction design, and visual design—did not exist.
So, why do we call contextual design Contextual Design? Because we are not talking about that (today’s) meaning of design, we are talking about product design. We’re talking about, how to figure out what people are doing in an area of work that the company wants to expand or improve. We wanted to figure out the right product to produce so that it will be bought, and money is made by the company. Contextual Design grew out of a question that John Whiteside (then manager of the Software Usability Engineering group at DEC) asked me: “How can we know what to make?” Contextual Design started as the answer to that question.
“How can we know what to make?”
But to do it well—so the product is successful—we also had to figure out how to put that product together. In other words, what features, what connections, what structure is presented to the user? This time was the emergence of usability as a goal of product design: Figuring out how to put it together was about making sure the user could use the product, how to bake in the usability. In those days, the structure was all pretty much a screen with drop-down menus or a form to fill in. You know, very simple user interface. So, when I talk about design, I’m talking about product design that works for the company’s business and the user. The design in Contextual Design refers to product design—usability, interaction, visual design…is part of that. And these concerns didn’t exist when we started. They came in much later.
X-Mentor: So now I’m curious, how is Contextual Design (CD) the process an answer to John’s question?
Well, I have always been a qualitative researcher, I’m an applied psychologist by training. I do not have a Computer Science degree, let’s be clear about that. As a qualitative researcher, when John asked his questions I thought, “What do you mean?” It seemed obvious to me. You go out into the field and talk with people about what they’re doing while they do it. Not just while they are interacting with the product. But while they’re doing the activity you (the company) think you’re trying to address. So, the key thing about Contextual Design and Contextual Inquiry, which is our field data gathering technique, is that you have to get out of your cubicle. Which, as you can imagine, was not at all done by engineers. So Contextual Design became and is a front-end design process. That means everything you need to do to define requirements (or user needs) and the product definition and design before coding starts.
Contextual Design (CD) answers John’s question because it begins with customer data up front, using that to drive what is made. There was no systematic customer-centered process being used at the time. It’s the data that transformed and directed what companies should do. CD helps them figure out how to characterize their market, what the people are doing, and what they might need that overlaps with what the business might be able to provide. The first half of CD, the first four steps produce an understanding of the people, the market, and high-level product concepts. The second half, the second four steps, is how to structure the product so it works for people. These steps emerged and have changed over time because until there was interactive UI (user interface), creating a UI wasn’t a significant step.
Contextual Design also helps a company make product because—as I eventually figured out—if the people tasked with defining, building, and shipping the product did not agree on what to make or sell nothing would get out the door. Product design was as much about the people as the data. I took a page from Deming and the quality movement (I started at DEC in a quality group). To do the work we brought together a cross-functional team: Product, Engineering, and usability folks, for example. Research and Design weren’t there until later, nor were content specialists. Cross-functional teams were doing all the CD steps, together! Which means, part of what’s going on with Contextual Design is figuring out how to get all of those people to interact well to get the work done. It was even more challenging because we were asking them to do something they don’t really know anything about—to understand people as psychologists and anthropologists do. They needed to do the work and get along until it was time to build something. And if they did that, we would together produce something they agreed was the right thing to build. Making teams work was—and is—Contextual Design.
Just to be clear because some folks aren’t. Contextual Design is not focused on usability. You get usability at the end of the process. CD is product design.
What’s Changed over the Years?
X-Mentor: Let’s talk about the Contextual Design process. What’s changed? When I was first introduced to Contextual Design, it started with collecting data. You know the Contextual Inquiry, the interpretation of that data, consolidating the data, envisioning, storytelling, and putting a picture around the user’s environment, and then getting to a prototype. But, really, how much has changed?
Karen: In the Contextual Design process?
X-Mentor: Yes. What we see today is diverse ways of looking at agile processes or design thinking. Aren’t they doing the same thing?
X-Mentor: Some version of it? What’s different?
Karen: Let’s separate a few things. Over the years software development methodologies have changed. It started with Waterfall. There was JAD (Joint Application Development). Now we’re on agile. But none of them defined what to do up front very well. As I said, Contextual Design is front-end product definition; a set of structured working meetings moving from talking with the customer, to synthesizing the data, and using it to figure out what to build. It collects and organizes high-quality, trusted data, and helps the team use it to decide what to make and how to structure it. And it is teachable to anyone. Changing how to code the product, how to organize developers, has little impact on the steps of CD. Software methodologies are all developed by developers trying to keep stakeholders from shifting requirements. But if you have a more systematic front-end design process like CD, it naturally stabilizes requirements.
Since none of the development methodologies, agile and all the rest of them, do not have a well-defined practice for front-end design. CD can sit at the front of any software development methodology. All of the methodologies that you’re interfacing with are really about how to get the product developed and out the door once you know what to make. Contextual Design is about what the company should make. As an industry, we’re always messing around with software methodology. But what doesn’t change is figuring out what the customer needs that the company can build and sell. The steps of CD did not change for 20 years. It was easy to take the findings of CD and adapt them to any software methodology.
That doesn’t mean that we don’t need to slant exactly what we do to suit the method. Agile was a challenge because of the short sprints and philosophy of not doing big up-front requirements. That’s why my business partner, Hugh Beyer, did a monograph on how to think about UX and agile. It’s been the most downloaded book in the Synthesis series published by Morgan Claypool. To get UX into the process, the industry had to “fix” agile by inventing Phase Zero and other workarounds to the method. But it is still basically the CD process.
X-Mentor: So, what changed it? Anything?
Karen: Yes. The basic steps of CD, described in our first book, served companies well irrespective of methodology or changes in technology for any kind of product until we had serious mobile devices, which does not include laptops. Not so much the beginning of the iPhone, but the beginning of everyone having a mobile phone like the iPhone. Until that point in time, we had worked on many, many systems and products, any number of business systems, any number of publishing systems, any number of products, cars, trucks, etc. We never needed to change the basic idea of what Contextual Design is and what to do. But once there was mobility, it changed the way people lived their life with technology.
“But once there was mobility, it changed the way people lived their life with technology.”
So, we started the “Cool Project” back in those days. (An InContext project that set out to discover what’s at the heart of transformative product experience.) I don’t know now, 15, 18 years ago. And we asked the question, “what makes things cool?” We went out to the field, of course, because that is what we do. And we talked with people about anything that they thought was cool, not just their mobile phones. From that data, we identified the Cool Concepts, which include the experience of what makes something cool in life, and to you as a person, and also the triangle of design, which defines what makes things cool in the product interaction. These new insights changed the method–the data we collected, how we organized it, used it for ideation, and structured the product. So real mobile devices changed how people used technology in their daily lives, so the method had to change.
But another change that impacted CD was the make-up of the team. We were no longer working only with developers. The UX field had grown so now, we had interaction and visual designers, and user researchers. And more marketers, product managers, and content specialists. We had HCI programs and their graduates. The teams we were working with changed their composition. The first version of Contextual Design was a practice shaped by developers. It was developers because the team was all developers. And the models we used in Contextual Design V1 to structure the information are very similar to the kind of modeling that developers are used to doing. But marketers, product managers, the UX folks (i.e., UX designers, user researchers, usability, etc.), and business leaders aren’t used to modeling that way. As the composition of the team and stakeholders changed, we needed to change how we communicated data to them and how we helped them design the product. Leading up to the Cool Project, we had been shifting how we presented models and steps in the second half of CD to include better ways to communicate data and to design interfaces. With the insights from the Cool Concepts, we took the opportunity to really update the steps of CD. We tuned them to include design for a cool experience and revamped the models to match the needs of the current team configuration.
The second edition of our book [Contextual Design: Design for Life,] incorporates the impact of real mobile devices and a changing team structure. These new models are all about how to understand the market, mobile life, and people’s experience in the world. And they’re also much more beautiful to make them compelling, simpler to read, and accessible. At the same time, we updated the second phase of CD to design for products that need real interaction design and products that span multiple platforms. We changed how we represented the system, to having more visual dimensions in the storyboarding, and interaction patterns laid on the user environment design, and then we have visual design guidance. We changed Contextual Design to suit the nature of the product today and the nature of the people on the team.
“CD did not change for years and years and years. The first book is used and is still used for over 25 years. Which I think is kind of a claim to fame.”
That’s it. CD did not change for years and years and years. The first book is used and is still used for over 25 years. Which I think is kind of a claim to fame. And I think it’s also related to the fact that Contextual Design can be learned by anyone who is not an anthropologist or a psychologist. We started with engineers. If we can get engineers to do this stuff, there is nobody who can’t do it. And, I’m all about no special people.
But now, we have another challenge. In the day of ‘remote,’ there’s now also remote Contextual Design. During the pandemic, we had to talk about how to do remote interviewing and what the limitations are. I’m working on a new monograph I’ll do with Morgan Claypool which will be on remote Contextual Design. Remote CD comes with a bit of a danger because it brings us back to the age-old resistance to actually getting out and talking with the customer in situ. “Yeah, if you can do it remotely. Why should you go into the field?” It’s almost like going back 35 years when I had to say: “Yes, Mr. Engineer, who is in Birkenstocks with a ripped T-shirt and shorts, you’re going to get dressed up, wear a tie, and I’m literally taking you out of your cube full of stacks of paper into the field.” That’s a problem. Because people don’t understand how much remote interviews constrain their focus, and therefore their ideation. My latest research is on hybrid vs remote work; when do we need to be in-person and when we do not need to be in-person for doing the work? What is the real value of each? We hope that will offer some guidance.
X-Mentor: Wow. An amazing story, Contextual Design made a dent, a big dent.
X-Mentor: I want to stay with this flow and go back to when we first met at Microsoft. This was back when I was with the Microsoft Business Intelligence Group in the mid-2000s. The work we were doing together was to coach business leaders and consult with teams on the values and principles of Contextual Design. You may not even be aware of how much impact that project had. We used your Rapid Contextual Design book as a guide to facilitate user-centered design conversations. It was actionable insights we could use immediately.
That project led to Microsoft’s Engineering Excellence Group catching word-of-mouth about the work we were doing. Then they went off to create their own customer-centric training program called “Scenario-focused Engineering.” The Microsoft Office Division picked up Scenario-focused Engineering training first and went on to train every full-time engineering role in the division – starting with the top echelon of management, then everyone under them. That’s over 3,000 Office FTE’s being trained in what is essentially user-centered design. And it didn’t stop there. Thousands within Microsoft were certified. Thousands more outside of Microsoft learned Scenario-focused Engineering. I see this as an example of where derivatives of Contextual Design have had an impact and influence not just at Microsoft, but globally.
X-Mentor: I want to talk about the coaching piece of Contextual Design. What are some of the experiences you’ve had and lessons you’ve learned along the way when coaching business leaders and training teams on the values and principles of Contextual Design?
Karen: I don’t know what you mean by business leader.
X-Mentor: Businessperson. Someone like a Product Head or GM of the company like you worked with in the Microsoft Business Intelligence Group.
Karen: I want to be clear. It is rare that we work at that level. We are generally hired by a manager. Sometimes we talk to somebody like a user researcher or a designer, or somebody fed-up with how they were doing things. And then they would get their manager, and I would talk to them, and then they get excited. I might come in and give a small talk to the developers and the architects and the product people, and whomever to see if they got excited and then we would make a project. Somebody might pull me in, maybe they would be at the director level, or they would be the project lead a lot of the time. They would have to go up to [business leaders] and advocate to bring me in. It wasn’t people like that [business leaders].
I was brought in because I’m known as a good speaker, and I can get people excited. If I get people excited, help them see why it is worth it to try something new, they hire you. If you don’t get people excited, guess what, they don’t hire you. Once we were in a company, if the team understand their customer, generate a great product concept that is well received by customers, they share their excitement. If they come together to make it. Well, guess what? Another group feels like, “Oh! We’re missing out.” Then that team works together to build and ship it and it is well received, now others in that company want to hire us too. In some companies we would have 10 projects, because they all want to feel like they’re getting the advantage. But first you must have an advantage. This is what we did, basically, grassroots change to introduce getting and using customer (user) data into the team. Whether you call it customer-centered design, user-centered design, experience design, UX, or whatever; the names have changed over 35 years, but in the end it all boils down to the same thing.
Make sure the human beings using the thing can get supported, enhanced, and delighted by the product you’re giving them. That’s it. Now, if that happens, more product is sold.
And to be clear, these results are not the result of any one UX person. Success is created by a cross-functional team working together to use the data, figure out what to build, prioritize what should come first, turn it into agile stories these days, and actually get it out the door. All these people have to work together. So, what happens is that the manager, leader, or the Director has some executive they report to. They give reports to the executive. And we would come in every so often and give the readout with the team. When we did that, the higher-level person would be there. We’d get them excited.
X-Mentor: Just on that point, can you speak to one of those meetings where you see what has been coming up from the team, and reported to the executive, has influenced a change in business direction?
Karen: They’re hiring us because they want to change.
Karen: For example, one marketing person who hired us, one of the significant changes that he made after he looked at the data is he canceled a bunch of projects. Canceling is a very important thing because we waste so much money when we make things that nobody wants. Just because 10 smart engineers in a room dreamed it up, or they couldn’t figure out what else to make, doesn’t mean it’s a good business idea. We influenced companies from the bottom up.
“Canceling is a very important thing because we waste so much money when we make things that nobody wants.”
Sometimes we are hired by a top executive who has worked with us before—some were even on a team when they were in their early career. They get a new challenge, and think, “This is a mess. We’re doing Contextual Design.” They call and we set up the project. They already know that they’re having a problem; not knowing what adjacencies to support, or their product is not being well received. In other words, if there’s a problem, they already know there’s a problem. They call us in to understand what’s going on. We identify (with CD) things that will intersect between what customers need and the business goals. I just want to emphasize this over and over again. A solution can’t just be what customers need, and it’s not mainly about beautiful UI design. A successful product is always about the overlap between this company’s capacity, what they’re good at, what they can do, and what the customer data is telling us. It’s about what the business cares about right now, meaning that line of the business that we’re reporting into. So, companies do make change. They make a new thing. They add different features. They change their products.
X-Mentor: Have you encountered a situation where a company has a need to accelerate Time-to-Market, or improve operational efficiency, or reduce cost. Things like that? What would that look like?
Karen: I wouldn’t use that language. It would look like: “We really want to be innovative. We want to do something else. We know we’re at the top, and we don’t want to lose it. We know somebody else is coming in. I want you (InContext) to come in and help us think about the next generation.” People don’t hire us to reduce costs or improve their process—they hire us to improve their products or develop new products, which includes getting to market in their timeframe. The focus of the project includes the business timeframe and how much innovation they can tolerate.
X-Mentor: What did you do with the situation you laid out—replacing your successful product to keep the market?
Karen: We run Contextual Design with their team but shift the focus of the ideation sessions. We work with product teams, not research teams, so it is a very practical approach. We start by making a cohesive cross-functional team that is responsible for the product and preferably is committed to what we are doing. When new innovation is needed, we shift their focus. For example, I would say, “Alright, we need a name for this new team. We’re going to eat the market of that product (the current successful one) we’re trying to beat.” Our whole job is to obviate it, to wipe it out. That focus changes the data we collect, changes the way we run ideation sessions. This is how we help them come up with what might be their future. Do they always do it, ship the new product idea? No. Because sometimes it scares them. Or it turns out that their salespeople don’t know how to sell it. Or it’s not really in the core market. Companies have a very hard time really deviating from their central mission. So yes, we have made an impact. Products have changed, sometimes a little and sometimes dramatically depending on what the business goal is. This happens because people whom we’ve trained, or we’ve worked with, advocate using CD and then work on the team. But then those people work their own organization until something ships. They make it happen. They talk to their upper management and get upper management on the bandwagon.
What I’m saying is that by impacting the industry—the whole idea of going into the field and figuring out what to make—user-centered design became accepted because we worked with product teams and they made it happen. And not just me, but all kinds of consultants, emerging professionals, and so forth. We worked with the teams. The teams get energized. They bring management along. It’s bottoms-up change.
X-Mentor: But what about the C-level? There is talk about Design needing a seat at the table.
Karen: It’s important for you to realize that the Chief Design Officer is new. Just like there were no UX type-people for years and years. First there were engineers that “became” user researchers and designers by using user-centered processes—without any title. They were all engineers. Then we started having college programs in HCI. That was the beginning of our field. Okay. Now we have a field, and all of this happened before there were any Chief Design Officers. The C-level followed the grassroots.
“It’s important for you to realize that the Chief Design Officer is new.”
Is it important to have that [Chief Design Officer] now? Sure, because then we have support from the top C-Level, and support from the teams, the grassroots. When the top and the teams both want to change practices, it works. But the important thing to realize is that if you don’t have the teams including all the cross-functions, you can’t get them to do the work. Without the team buy-in, you are dead in the water. If you don’t have the top, you can probably convince enough people responsible for the product to try going to the customer. We called it guerilla user-centered design. But if you can’t get the team who’s responsible, the product manager, the engineers, the designers, the user researchers, to be on the same page—you can make nothing. Upper management can declare what they want—but unless they are going to fire folks for non-compliance—they have to bring the teams along. It’s not any different from the backlash that happened when the company said after the height of the pandemic, “You have to come back to work in person five days a week.” The workers said, “No.” And it was higher level that changed. It’s important to understand the power of the grassroots.
X-Mentor: I’m thinking about Contextual Design being introduced as an alternative to the then status quo of engineering and feature-driven models.
Karen: Yes. Engineering-driven design.
X-Mentor: And there you are, Karen, trying really to transform the way someone is working.
Karen: Yes. And not everybody was happy.
X-Mentor: Yeah, because people resist change. They tend to stick with the status quo. And if you try to force people to change, we know now from the research that’s been done by David Schonthal and Loran Nordgren at Kellogg School of Management, there’s this thing called “reactance,” which is the impulse to resist being changed. So, if an innovator is trying to force a new way of working, it can just shut people off to the new idea.
Karen: Yes. And so, you have to know how to get through that. It’s not by evangelizing user data or UX.
As soon as you are trying to convince and sell you lose. We don’t do that. Instead, we focus on helping teams realize that they need to do something else if they want to succeed more.
It’s storytelling from the trenches—and developers recognizing their own frustrating experiences. As I said, if you can’t get that group to want to do it, the new practice, nothing will happen. If we can’t bring the rest of the team along, or if they resist the whole time, they won’t do the necessary work. They won’t pull together. Teams have to commit to the CD process to get a result. We say try it once—then decide. If you get the group to do it, and somebody pays for it in my case, the team will show results. They will know and share the customer data. They will make and iterate a prototype with users. Now they have something to show leadership and other teams. And folks will say, “Hmm… we learned something. We have direction.”
Adopting a user-centered process is always about engaging the team—even today—even when the company as a whole has UX folks and thinks of itself as having adopted a UX process.
Design must use the Language of Business
X-Mentor: This is where I’d like to go next. The language that is used and improving on how we communicate the business impact of design.
X-Mentor: What does Design need to understand about the business and vice versa? How might we create an effective common language to improve understanding? What might you say to those people who say they don’t understand the business value of design?
“The language of business is simple. Is the product making money?”
Karen: The language of business is simple. Is the product making money? Is it gaining market share? Is the product a priority for this year’s goals? Is the product getting good outside ratings—like in the auto industry. If you go to work for a car company, and we have worked with many, they care about the JD Power score. Or maybe they care about Consumer Reports. If you look at those evaluations today, they are going to talk about the user experience. So then, companies have to care about user experience. But talking business means knowing that the goal of the project is to raise the JD Power score. That is their motivation for making sure they care about the customer experience—it gets a public score which increases sales.
Today UX is just a necessary part of good product design. Too often UX and designers are defensive. No one asks, do we need developers? How else would you build the product? I think we have proved the case for user research and for design because you simply can’t put together a successful product today without them. Having a seat at the C-level helps the company have a coherent strategy; it ensures a dialogue between UX (design and research), engineering, and product. That is your top-level cross-functional team ensuring resources all the way down into the cross-functional product teams—irrespective of the reporting structure.
But will that ensure that you don’t have to bring along folks on the team or their managers; get them to go out to the customer—to be involved? No, with every person we may get challenges. It comes with the territory in most companies. Researchers and designers need to understand that doing good research and good design doesn’t, by itself, guarantee product success in the market. We need to run our projects and do the design with business success in mind. And we need to be able to argue why this product will get market share. It is up to us to learn, understand, and talk about business priority. We can’t expect them to understand what design is focused on—any more than leadership will be able to talk code.
X-Mentor: So UX needs to learn how to talk to the business.
Karen: Yes—and we don’t do a good job of teaching it to new UX folks getting degrees—or those on the team already who don’t know. But good managers make sure that they are constantly sharing the business goals and helping shape their people towards the business goals. As one CEO that we worked with a lot would say, “I don’t care if the customers like it. Can we make any money?” “Please go do a business analysis and tell me if we can sell this.” This person is utterly committed to Contextual Design. But she wants us to identify the things that will advance the goals of the business. She’s not saying, make sure they have the best customer experience. She’s saying, make sure they have the best customer experience that we can build that advances the goals of the business—making money.
“She’s saying, make sure they have the best customer experience that we can build that advances the goals of the business—making money.”
X-Mentor: So, to successfully make connections between Design and the rest of the organization Design has to advance the business goals.
Karen: Yes, and we do that by having and using good user-centered design practices well. To advance the goals of the business we know we also have to get them all to use these techniques—not just send us off to do it and then be left with the sorry task of trying to convince them of its values. Which is why I talk so much about cross-functional teams pulling together using a user-centered design process. Even when a company is really good about having designers and user researchers, design and product need to want the research. They need to bring research into their discussions. They need to be a team. User researchers are often key to making change in the company. People who are good at running processes like user-centered design, nudging folks to be involved, and articulating customer insights that matter as they relate to the tested product ideas—these folks change the company and the industry. But it all starts, from my perspective, with valuing data on the lives of the people in your target market. Without that data, you have no ground for arguing that you know what you are talking about—why anyone would buy your product concept.
X-Mentor: Got it. The parting question here is about bringing together something old and something new to create something better. In Ginni Rometti’s (Former CEO of IBM) new book, Good Power, a great book that just came out this week, she talks about the brain of good power being bringing these old things that are tried and true to new ideas, to create something better. This is what I was thinking about when you were talking about the origins of Contextual Design, something you created decades ago, and it has this enduring quality to it. So, when you’re thinking about Contextual Design and bringing something new to create something better. What might you have to say?
Karen: My daughter is a user researcher. She likes to say that she’s second-generation Holtzblatt. She does great work inside a company. She uses different methodologies than I do. They’re really interesting. Front-end design methodologies will shift and change as people make them their own. But my goal with Contextual Design is really about something very simple. Go to the customer and understand what’s going on. Organize the data and use it to drive ideation of what to make. My legacy, if I have one, or the legacy of all of us who started pushing good qualitative data into product design, is that companies are doing it. They may not use all of CD or even call it CD—just as you didn’t at Microsoft. But hey, you are using customer data and have a process to drive it into the product. I know, every generation wants to find its own methodologies; they want to say, this is better. I don’t care if folks use all of Contextual Design—but they do need to figure out how to do all the things that CD leads a team through. Use whatever word you want but ask yourselves. Do you go out and really understand your customers, your users? Do you understand their life and work context? Do you understand the situation that they’re in? Do you understand what they are trying to do with technology, with life, and with family? Okay, good. Then as far as I’m concerned, you’re using Contextual Design. And do you have a process to help your cross-functional team work together to collect, organize, and use the data to define the product? That is also what Contextual Design brings to the table.
If you want a repeatable process that absolutely will work, and a way of organizing the data that you can return to, and that will work to drive design and product success? Well, maybe you should try something that’s got legs for 35 years and some books on it too.
X-Mentor: Karen, FANTASTIC! I mean. It’s amazing how you were able to just fluently move from one question to the next even before I got to them. It was great having you on The X-Mentor. We are so fortunate to have you share your deep and immense knowledge and insights with us today. Thank you!
ABOUT THE AUTHOR(S)
Karen Holtzblatt is the CEO of InContext Design, author, and visionary behind Contextual Inquiry and Contextual Design.
Greg Parrott is The X-Mentor and publisher of The X-Interviews.
Thanks for reading The X-Mentor! Subscribe for free to receive new posts and support my work.