Customer-centered design involves organizational change. Organizational change is not easily embraced, but it is necessary in order to make good products that support the customer. Companies involved in product development and in information technology are moving from being technology driven to being customer drivenensuring that what they ship improves people's work and lives. Accompanying this shift in attitude is the need for requirements and design techniques that successfully incorporate customer data into the product development process. The increasing willingness to try new things makes change possible.
Although development teams, marketers, business analysts, and managers are ready for a customer-centered process, introducing change means changing an organization's habits and culture. Sometimes it means just trying to slow down the relentless drive of an organization to ship "something" by a given date. Changing processes means intervening in everyday practice to think about what you are doing and to choose what you want to do in the design space. Even people who want to try something different may find it challenging to achieve customer-centered design.
Contextual Design is a set of steps to achieve customer-centered design in organizations. It was developed over the last 11 years by working with real development teams to put together a process that can work for customers, for the design, and for organizations. It gives organizations and designers an explicit way to gather, interpret, and design from customer data within the constraints of organizations. I and others have taught, coached, preached, and trained leaders in contextual techniques, sometimes knowingly and sometimes through papers and attendance at seminars. These professionals are out there moving their organizations toward practical customer-centered processes.
The formal description of Contextual Design as written in our book [Beyer, H., and Holtzblatt, K. Contextual Design: Defining Customer-Centered Systems, Morgan Kaufmann Publishers, Inc., San Francisco, 1998.], like any "general" description of a method, is an idealized model of the process itself. How Contextual Design shows up on any project, even when we lead it, depends on the focus and goals of that project, its resources, its schedule, and its culture. Even if Contextual Design were the perfect method of defining customer-centered systems, getting real people in real organizations to change their practice is always difficult. Everywhere I go I am asked by software development professionals how they can get customer-centered techniques going in their organizations. They worry about having time to do "the whole thing": Do you have to use all the parts of the method? They worry about the fit with their own existing methods: What do we do with existing techniques? They worry about whether their workers can really be trained: How do we bring our people up to speed? And they want to know what happens when someone other than the founder of the method tries it: What happens within real companies when other people try to implement these techniques?
The neat part about teaching, coaching, and training coaches in Contextual Inquiry and Design for the past decade is that now all kinds of people are trying things out and incorporating techniques into their own processes. They are building on our ideas and others' ideas to create new ways of doing things. Our ideas have become the starting place for putting new practices in place.
At our annual SIG on contextual techniques at CHI 98, a number of usability and user interface professionals related using Contextual Design techniques at their organizations. This special issue of interactions contains three of those stories and an overview of the Contextual Design process. Together these articles provide the flavor of what it is like to bring customer-centered processes into your organization: the feelings, the struggles, the adaptations, and the successes in changing both the people and the products.
The first article is about Contextual Design itself. Hugh Beyer walks us through the steps of the Contextual Design process, talking about how we have used and tailored our process to our customers' problems. I always tell my clients, "Before you go changing a method you should try using it the way it was designed. Once you understand why the parts are there then you can pick and choose." This article discusses the parts and their purposes and points the reader to additional resources.
The rest of the articles were written by people we have trained. They tell their story of applying contextual techniques while dancing to the tune of their organizations. These are tales of real projects run in real organizations by people who understand these and related techniques. Together these professionals talk about how they handled training and involving people in their organizations. They discuss how they tailored Contextual Design to suit their organizations. They describe how Contextual Design can become the backbone methodology for front-end design by choosing what models and techniques to use for a project and adding other techniques familiar to the team. They tell the story of the customers' response to the new designs.
Teresa Cleary describes the use of contextual data at Cabletron to look at the requirements for network device management. She talks about how Contextual Data changed the team's understanding of the design problem and influenced adoption of the method by the organization. Her goal was to spread the word about contextual techniques and involve lots of people. She was challenged to get many people on the team and still keep things moving. And she had to find ways to communicate to other members (developers and managers) of the organization who were not involved in the data collection. She describes how they got people involved in talking about the data and applying it to their design problem.
Chris Rockwell talks about his project at Hewlett Packard to redesign a product to install and update software on HP workstations. He describes how marketing concepts such as "value propositions" have been incorporated into the process and gives an interesting twist to mock-up interviews by conducting them remotely. Rockwell also emphasizes the power of customer data gathered from a clear project focus to direct decision making and give people a lever to say "no" to last-minute requirement changes. And he quotes the customers' responses to the changes.
John Ims at DST describes a wonderfully ambitious project to change the internal software that supports people in a call center that processes requests from shareholders about the status of their mutual fund accounts. Ims had the challenge of bringing large groups of people up to speed on both customer-centered techniques and basic UI design. He describes a mentoring process and the formation of a creative environment for discussing design solutions. He talks about the new deal fashioned between the designers and developers to code what was designed, changing it only with consultation from the business analyst designers. He too incorporates more classic usability metrics and methods into the process and is honest about what happens when upper management gets attached to their preferred design ideas.
I am pleased that these cases produced both organizational and product success. The worst thing that can happen when introducing new processes is to try something and have it fail. Failure sours an organization to risk and few organizations will soon try again. So let us use these stories to learn what worked and what didn't and find ways to keep pushing and cajoling organizations to get better and better at designing from customer data.
©1999 ACM 1072-5220/99/0100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 1999 ACM, Inc.