Contextual Design vs. Feature Driven Development

Last modified October 27, 2022

“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.

Contextual Design vs. Feature-Driven-Development

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:

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.



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!

◀ Back to all blogs