Everything we do starts with the user and ends with user validation. We form our understanding through field research, talking to users where they live and work, while they do the activities we are designing for. We may augment field visits with market research, surveys, or other techniques but we never substitute these other techniques for going to the field. The data is richer and generates more insight than any other; we never trade this off.

User data is a given, but core insight of the Cool Project was that design for life is not the same as design for task or design of technology. Products today allow people to mix their lives and work to a greater degree than ever, and however much we all joke and complain about it, we like it. We like being able to settle a work crisis while at our child’s baseball game; we like cruising vacation sites during a break at work. Any design has to consider the whole of life if it’s going to fit into life—if it’s going to be a product or a service people call cool.

Hearing about the user is one thing; understanding and embodying knowledge about the user at a gut level is another. Because people are people, just telling them information about the user doesn’t really communicate—not at the level necessary for design. So we design immersion experiences throughout the process in which team members experience the lives of their users over and over. Whether it’s participating in an interview, hearing the story in an Interpretation Session, doing or walking a consolidated model, or testing a design, we constantly bring designers face-to-face with the world of their users in ways that make it impossible to ignore. And this immersion naturally tunes the “gut feel” of the team so they naturally become user-centered designers.

There’s rarely only one useful way to look at a problem and in Contextual Design we rarely look at a problem in one way. We take notes of an interview—and build models. We don’t build one—each different model gives a different perspective. Capturing issues in a Wall Walk, we are perfectly happy to capture contradictory issues if people are seeing different things in the data. We don’t do one vision—we do several, and there’s no need for them to be compatible.

It’s a core principle of all our techniques that we have to work with the strengths and limitations of being human rather than against them. Some methods require huge amounts of slow meticulous tracking or thought, the original Quality Function Deployment process, for example; we find that few people can stick with that level of detail. If people don’t want to use the process, no matter how valuable it is, it won’t be used. Similarly it’s usual to assume that writing up a report or sending a memo will communicate; we don’t depend on it. Some data gathering methods ask for total objectivity from the interviewer; we don’t think that’s possible and use the interviewer’s subjectivity instead. Nearly every organization acts as though people can truly participate by sitting still in a meeting and listening passively; we find that people invariably zone out in such situations.

Techniques for managing teams are never an afterthought in Contextual Design. Every piece of the method has been developed with the understanding that it will be performed by a group of people working together, rather than by an individual. Certainly you can do every step as an individual, but that’s not how we developed or thought about the process. Nor is that the typical way of working in most companies.

Every team conversation in Contextual Design has an externalized form. The discussion about implications of an interview are captured in notes and models in the Interpretation Session. The vision is captured on flip charts. The User Environment Design is captured in a diagram. And so for every step—there’s always a way to put the conversation on a piece of paper (or an online document) and in front of the eyes of the team, even if that’s just a simple list.

Throughout the process, one key technique for managing teams is to name the concepts we want teams to manage. We start by naming roles: the moderator, the notetaker, the modeler. Names bestow power—the moderator is allowed to tell one person to stop talking so another can make their point; the notetaker is allowed to rephrase a point in a succinct and direct way (and the rest of the team is allowed to push back if they don’t think the phrasing reflects their intent). But this power is not an imposition on others—this is power given freely so that the rest of the team is free not to worry about these concerns.

We end this list of principles where we began: with the user. Throughout Contextual Design, we never forget that the user is the only real measure of the design. Before visioning, the user is the only authority about what is true in their lives, what they’re trying to accomplish, and how they want to accomplish it. After Visioning, the user is the only measure for whether any design idea is any good. Prototyping isn’t just a nice-to-have failsafe to make sure that your design is good. Prototyping is an integral part of the design process. If you’re arguing about what to ship stakes are high and, probably, so are emotions. If you’re arguing about what to test, stakes are much lower. User data and user tests are the ground on which your design rests—and no one really wants to argue with the ground. Becoming a data-based organization means that you have the user data you need to make arbitration possible. And looking to external data to help decision making is another way to remove interpersonal friction and level power. With data, power is in the user value—not the opinion of the smartest, loudest, or most important person in the room.

and designing the right product for your business. A real equal partnership between user research, design, and product management and a deep respect for UX professionals and their function by development is critical for true user-centered design. So we have come a long way, but the organizational change mission of our work—and yours too—is not over.