Failing product teams work under quiet assumptions.
“Users will think the way we do.”
“This is basic; everyone knows it.”
“We can explain it if needed.”
These assumptions feel reasonable because they are grounded in our own context. User research keeps showing how quickly that ground gives way.
Dan Russell, who studied how people search at Google for years, once described a moment that captures the gap. He was interviewing a bus driver preparing for a certification exam. She was scrolling through a 100-page web document, line by line, looking for a specific regulation. When he asked why she wasn’t using the browser’s find-in-page shortcut, her answer was simple. She didn’t know the feature existed.
To a product team, that sounds surprising. In actual use, it is ordinary. What feels “basic” is rarely universal knowledge. It is the familiarity built up over years by the tools, habits, and mental models of a tech-savvy product team.
That familiarity is context. This series on Contextual Design moves from core concepts to applied research. The first piece covers what context of use is, why asking users directly is not enough, and the four components that describe a real situation of use.
What Happens When Context Is Ignored
Most people agree that context matters. In practice, many teams quietly break with it.
The cause is rarely carelessness. The pressure to ship fast shifts behavior slowly, until research stops looking like research.
Research Trapped in the Meeting Room
When research gets separated from reality, a predictable pattern emerges:
- Interviews happen only over Zoom.
- Questions are built on internal assumptions.
- Slide-based personas stand in for actual users.
When the environment disappears, so do the interruptions, workarounds, and constraints. The output looks clean and professional. It is also incomplete.
Jumping to Synthesis Without Observation
Product teams tend to love synthesis. The instinct is to jump straight to insights, patterns, and solutions.
This skips the most important step: finding the common threads in raw observation. When a team has not seen the unfiltered behavior, members trust the conclusions less and argue about them more. Synthesis belongs at the end of research, not at the start.
Building Solutions Too Quickly
This is the most common failure mode. The moment a problem sounds familiar, the team runs to the solution.
- “Let’s add a shortcut.”
- “Let’s automate this.”
- “Let’s add a toggle.”
Premature solutions flatten the context. They lock the team’s thinking before the problem is fully understood.
The “Representative User” Illusion
Personas can be useful, but averaging users out usually moves the team further from reality. Real users do not behave like averages:
- They contradict each other.
- They act inconsistently across sessions.
- They adapt to constraints in different ways.
Context-based research surfaces this variation. Over-simplification hides it. Faster synthesis, cleaner narratives, and easier alignment can feel efficient. Speed without context produces the kind of confidence that reaches failure faster.
What “Context of Use” Actually Means
A product does not carry meaning on its own.
- A feature is not useful by default.
- A UI is not easy to use by default.
- A workflow is not intuitive by default.
These qualities only exist inside a specific context of use. The term comes from ISO 9241-11, the international standard on usability, which defines usability itself as the outcome of users achieving goals in a specified context — not as a property of the product.
Products Only Have Meaning in Real Situations
Product teams often evaluate features in isolation, against their own standards:
- Is this feature clear?
- Is this flow simple?
- Is this interaction efficient?
Users never encounter the product the way a product team sees it on a screen share. They meet it while:
- Trying to complete a task with a specific goal in mind (tasks and goals).
- Working under limited time and attention (cognitive load).
- Using imperfect or constrained tools (equipment constraints).
- Sitting inside a noisy or socially complex space (environmental constraints).
This is why a feature that looked obviously useful in a design review can feel confusing, irrelevant, or stressful when it lands in real conditions.
Why Asking Users What They Want Fails
“Let’s just ask the users.”
This sounds user-centered. In practice, it can produce confident answers and misleading conclusions. The problem is not that users lie. The problem is that what people say they prefer and what they actually do in real situations are often different.
People Don’t Know What They Want
When you ask users “what do you want?”, they usually do one of three things:
- Describe an ideal world that does not exist.
- Describe a feature they saw somewhere else.
- Rationalize their current behavior after the fact.
None of these reflect what they actually do in real use. This is not a moral failing in users. It is how human cognition works. Most behavior is habitual, context-dependent, and reactive — not deliberate and articulable.
The Limits of Surveys and Focus Groups
Surveys and focus groups carry structural limits:
- They separate users from their real environment.
- They force reflection in place of behavior.
- They reward confident phrasing over accurate description.
The result is opinions, not reality. This is why a feature that polled well in opinion-based research can underperform after launch.
Goals vs. Solutions
One of the most common mistakes in product discovery is confusing goals with solutions. Users often speak in the shape of solutions:
- “I need a faster dashboard.”
- “I want more filters.”
- “I want this automated.”
These are solutions, not goals. Each one is shaped by what the speaker already knows, which means it can only describe part of the underlying situation. The harder, more useful questions sit underneath:
- Why is this needed?
- What is the user trying to achieve?
- What in the current workflow is creating friction?
What Behavior in Context Reveals
Instead of asking what users want, the team should focus on understanding what users do:
- What is the user trying to accomplish?
- How are they doing it today?
- Where do they struggle or slow down?
- What workarounds have they built?
These questions expose the constraints users live with. The constraints are exactly where opportunities for real value tend to sit.
The Four Components of Context of Use
Context of use describes the full situation in which a product is used — not only the users, but the users and the system around them.
It breaks down into four components:
| Component | What it covers | Why it matters |
|---|---|---|
| Users | Who is using the product, including experience level, mental models, prior knowledge, and expectations | Two users with similar demographics can behave very differently depending on what they know and what they assume |
| Tasks | What the user is actually trying to achieve, beyond what a feature name suggests | Products are often a small step inside a larger goal, and that larger goal shapes how they get used |
| Equipment | Devices, software, input methods, and workarounds involved in completing the task | Tool constraints shape behavior more strongly than teams expect, and they explain a lot of unexpected user actions |
| Environment | Physical and social conditions, including noise, interruptions, pressure, and hierarchy | A workflow that looks simple in isolation can break under real-world surroundings |
Users: Mental Models, Prior Knowledge, Expectations
Who is using this product?
- Experience level.
- Mental models.
- What the user already knows.
- What the user assumes about how the product works.
Two users who look identical on a demographic chart can behave in opposite ways once their mental models diverge.
Tasks: The Real Goal Behind the Behavior
What is the user actually trying to do?
Not what the team thinks. Not what the feature name implies. The real goal sits behind the surface behavior. A product is often one small step inside a much larger task.
Equipment: Devices, Software, Workarounds
What tools are involved?
- Device type.
- Software environment.
- Input methods.
- Workarounds and shortcuts.
Equipment constraints shape user behavior far more than teams typically assume.
Environment: Physical and Social Conditions
Where is the product used?
- Physical environment (noise, motion, interruptions).
- Social environment (pressure, hierarchy, collaboration).
A workflow that feels “simple” can fall apart when the environment shifts. This leads to a core principle:
Usability depends on context of use. Without context, usability is only a theoretical idea.
Consider the difference between coding in a quiet cafe and coding in a loud open office. Same person, same laptop, same code. Once the environment changes, focus, error rate, and even working style change with it. Products behave the same way. Designing without regard for the environment leaves the team unable to answer “why are users making so many mistakes here?”
With Context vs. Without Context: How Decisions Change
| Decision area | Without context | With context |
|---|---|---|
| Product debate | Feature-led claims like “users need this” or “competitors have it” | Discussions grounded in observed workflows and real situations |
| Prioritization | Everything feels important; trade-offs feel arbitrary | Context narrows the options and makes “why now” clear |
| Decision dynamics | Seniority and intuition drive decisions | Observed reality becomes the shared reference point |
| Execution quality | Over-built work, slow execution because constraints are unclear | Focused execution that fits the actual constraints |
| PRDs and requirements | Feature lists without situational grounding | Requirements framed by constraints and desired outcomes |
| Team trust | Repeated justification and re-debate of past decisions | Shared understanding and trust in judgment |
| Language used | “I think…”, “This seems confusing to me” | “What we observed was…”, “This breaks the user’s workflow” |
Without context, teams fall back on opinion, intuition, and past experience to fill in gaps. Decisions still get made, but they are heavy, fragile, and hard to defend.
When context is clear and shared, the character of decision-making shifts. Instead of arguing about what each person believes, the team starts reasoning from what was observed. Context does not remove disagreement. It changes what the disagreement is about.
Instead of arguing about preferences between teammates, the team starts debating interpretations of the user’s actual reality. That shift alone speeds decisions up, improves execution quality, and builds trust over time.
One under-appreciated benefit of context is that it becomes a shared reference point. Instead of “this seems confusing,” a teammate can say “this breaks the workflow we observed” or “this adds meaningful friction at this step.” That change in language changes the tone of collaboration.
Conclusion
Context of use is not a soft idea. It is the ground that everything else in user research stands on. Without it, features get evaluated against the team’s preferences, surveys collect opinions instead of behavior, and personas hide the variation that matters most.
The four components — Users, Tasks, Equipment, Environment — are not a checklist to fill in. They are a frame for noticing what is already shaping every user’s experience, whether the team observes it or not.
The shift is not from disagreement to agreement. It is from arguing about preferences to interpreting observed reality together. That shift is what makes context worth the effort.
The next article in this series looks at how to capture context directly through Contextual Inquiry — what it is, the core principles behind it, and how it differs from a standard user interview.
Contextual Design Series
(1) Context of Use: Why User Research Without Context Fails
(2) What Is Contextual Inquiry? Definition and 4 Core Principles
(3) Contextual Design: Turning User Observations into Product Decisions