“Good design, when it’s done well, becomes invisible. It’s only when it’s done poorly that we notice it. Think of it as a room’s air conditioning. We only notice it when it’s too hot, too cold, making too much noise, or the unit is dripping on us. Yet, if the air conditioning is perfect, nobody says anything and we focus, instead, on the task at hand.”
- Jared Spool

This quote (or, at least, the first line of it) is quite popular in the design world, often shortened to simply: “Good design is invisible”. It’s so well-known because it very neatly sums up a fundamental aspect of design: that design, itself, is never the end product, but rather the means to an end. Ideally, design is the thing that positions itself in-between the user and the solution and becomes the bridge; when a design is perfect, the user won’t even notice that they’ve left solid ground and stepped onto a bridge at all.

For this to happen in the applications and websites that we develop, the UI specialist needs to live in that in-between space as well; close enough to the user and their daily life to understand their processes, habits, motivations, and problems…but enough of an outsider to be able to offer a fresh perspective and new solution. Someone who’s completely enmeshed in a system will have a difficult time stepping back to objectively evaluate it, but someone who’s a total outsider won’t have a deep enough of an understanding of the systems, problems, and goals to find a realistic answer. It’s a delicate balance – and one that’s intrinsic to the process of contextual design.

Different Approaches to Problem Solving

Contextual design is an approach to user experience (UX) design and problem solving that was developed by Hugh Beyer and Karen Holtzblatt. Basically, it outlines a process that begins with observation of the user’s daily context. This means that, rather than taking the user out of their daily flow in order to join a focus group or complete a UX interview, the designer, developer, or researcher joins the user in their environment to observe the natural behavior of the user.

This is a particularly interesting approach because it’s inverted from the process of teams who build products using a Feature-Driven-Development (FDD) model. In FDD, the software itself is the starting point, and the emphasis is on the quick and iterative creation of Minimum Viable Products (MVPs) – with the goal of being quick and adaptive. While FDD processes do often include user interviews, they tend to be near the end of the feature development cycle and the information gathered there informs a future version of the product. Furthermore, the user interviews held in FDD-focused companies tend to follow a more heavily structured approach: bringing a user out of their daily work and into the office of the company developing the software, having them complete a list of pre-set tasks in order to test a specific feature, asking targeted questions, etc.

In contrast, contextual design is more organic, moves more slowly, and places the emphasis on deep research before feature development begins. It requires a greater investment of time and effort upfront, before any code is written. User interviews are more open-ended and conducted in the user’s workplace or home. The user is asked to go about their daily routine or tasks, and the researcher simply observes. Sometimes a researcher might be partnered with a user to shadow them through their day, giving the researcher the opportunity to ask clarifying questions as needed rather than working from a pre-set list of questions or prompts. Finally, the researcher will share their notes and insights with the user in a wrap-up conversation, giving the user the opportunity to correct or clarify any misunderstandings. When this stage is complete, the researcher meets with their teammates (who have been doing the same work with other users) to compare and contrast their findings. The data gathered from these observations and conversations are then organized into flow models and/or user personas, which inform feature development decisions.

In short:

• Contextual design takes the time to look carefully at the user’s natural environment and context with minimal interference/guidance, then uses the data gathered during that observation to inform the design and development of a full-featured product.
• FDD begins with design and development of an MVP (often based on designer/developer assumptions), then puts that product in front of users for guided testing. Based on that first version, they’ll keep what works, throw away what doesn’t, and iterate on the existing product based on what was learned from that attempt.

Solving the “Faster Horse” Problem

Why would a team choose to go through all this additional effort in order to gather information? Couldn’t they just ask the users, in a straightforward way, what they need us to build? Wouldn’t that be the path of least resistance and the most clear approach? Unfortunately, it’s not quite that easy.

It’s said that, when once asked about the innovative process that lead to the development of the Model T, Henry Ford replied: “If I had asked people what they wanted, they would have said faster horses.” Today, there’s a fair amount of doubt that Henry Ford actually said this, but I don’t think it detracts from the truth of the statement – in fact, I’d bet that anyone who’s been part of a UX interview with a user would vouch for its accuracy.

Part of the challenge inherent in software development is that the creators must have a complete understanding of the needs, motivations, and challenges of the user – and yet, these are things the user, themselves, will struggle to articulate. Because the user is still inside the system, working within constraints, patterns, and biases they might not even be conscious of, they are incapable of viewing their own system with a truly objective and critical eye. They’re almost certainly aware of some shortcomings or failures in the system (usually where they become pain points or obstructions for their own workflow). However, when they’re asked about potential solutions for these problems, the answers they come up with will still be bound by the constraints of the system they are enmeshed in; they’ll ask for faster horses, not cars.

Contextual design draws on a background of anthropology and psychology, placing the researcher as an outside observer and allowing them to (briefly, but fully) participate in the existing system with the user. This allows them to identify which parts of the system are actually necessary and required, and which are more flexible – or possibly even incorrect or flawed – and can be replaced or “disrupted” by a new solution that (hopefully) improves the system as a whole.

What are the users’ goals? What specific steps or tasks do they take to achieve those goals? How much time does this take? Where are there pain points or common points of failure? Where is there the highest risk for error and where is a human touch required? What emotions do users experience as they complete these tasks? What else is the user doing while they complete these tasks? How does this work fit into the daily routine of the user? How do different users approach the same goal, and how much do the tasks in this process vary from user to user? These are all questions that can be answered through the contextual design observation process, and then used to make data-driven feature development and design decisions.

Benefits and Drawbacks of the Contextual Design Methodology

There are both pros and cons to taking a contextual design approach to building software.

Pros

• Extremely user-focused. Suffice to say, this method is user-centered at its very core. Because the process begins with user / designer collaboration and conversation, that first step will inform everything else that happens afterwards.
• Data-driven and science-based. It’s incredibly easy for assumptions and biases to sneak their way into the world of software development – in fact, I’d argue that some amount of natural bias is both inherent and unavoidable. Your team members only have an intimate understanding of their own life experiences; if that isn’t countered by diverse hiring, gathering objective data, and working closely with users, then the software that team creates will undoubtably be a reflection of those biases. Contextual design pushes your team outside their bubble and places the user’s experiences and needs first and foremost in the process.
• Creates long-lasting solutions not influenced by trends. Tools, languages, frameworks, design styles, even hardware and devices all come and go. When you’re working within the tech bubble, it’s easy to get sucked into whatever feels like the right solution right now or whatever’s newest, coolest, and most interesting. However, those trends often reflect what’s most compelling for the designers or developers – not necessarily for the users. By identifying the gaps and needs on the user’s end first, the designer or developer is encouraged to choose the right tool to solve the problem at hand as opposed to automatically reaching for their newest or most favorite tool.

Cons

• Resource-heavy, especially upfront. As you might imagine, taking on a project like this requires a fair bit of work. You’ll either need to have in-house UX designers and researchers you can assign to this work (and a client willing to participate), or you’ll need to hire an agency or consulting business. The observation itself will likely take a few days to a week, then you’ll need 2-3 weeks to analyze and consolidate the data. Once you have the conclusions, you can begin work on the actual problem-solving and design for the product, itself. This isn’t a sprint or a quick side project; contextual design requires both time and personnel that can be fully dedicated to the project.
  • However, it is worth noting that this process doesn’t have to be repeated very often unless something significant changes on the user end. Assuming no large disruption, this upfront investment (if done correctly) is one that you will be able to reap the benefits of for many years, across multiple projects.
• Needs a strong UX / Design team. As mentioned above, you’ll either need to have a strong in-house team, or be willing to outsource the observation and data analyzation aspects of this project. Even if you choose to outsource, however, you should still have at least a few designers on your team who will be able to make use of the data you’ve collected – it’s not worth taking on such a project if you don’t have people on your team who will be able to properly make use of the results.
• Doesn’t move as quickly as other methods. The Agile and FDD approaches to software development place a huge emphasis on quickly producing the minimum viable product and then repeatedly iterating on that product, sometimes leading to a trial-and-error attitude (ie. “Move fast and break things”). While contextual design is also iterative, it is not intended to be fast-moving, instead placing emphasis on intentionality and thoroughness. Both approaches are valid, but they place emphasis on different places and one of the most notable differences is time to first product.

Should my Team be Using the Contextual Design Method?

Ultimately, the decision about whether contextual design is right for your team is something that you’ll have to decide on your own. I don’t believe that there’s a “right” or “wrong” approach, personally – different teams and different products will find different methodologies to suit them, based on team size, available resources, the type of product being developed, the experience level of team members, and so much more. However, I do think that every approach to design has something of value that can be learned and potentially incorporated into your existing processes. Hopefully, you found something in the contextual design method that will inform and improve the process for your team!