Contextual Inquiry: How to Understand User Needs Before You Build

Contextual inquiry is a user research method in which you watch people do their real work, in the place they normally do it, and ask questions as the work happens. Instead of asking someone to describe their workflow from memory, you sit beside them while they complete it. You see the tools they use, the decisions they make, the shortcuts they take and the problems they quietly work around.

The method comes from Hugh Beyer and Karen Holtzblatt's book Contextual Design, and it rests on four principles:

• Context: go where the work happens and observe the work itself, not a summary of it.
• Partnership: treat the user as the expert and yourself as an apprentice learning the job.
• Interpretation: check what you think you saw with the user, in the moment, instead of guessing later.
• Focus: agree in advance which part of the work you are studying, so the session does not drift.

The goal is simple: understand the real experience before designing the solution. We use contextual inquiry early in a project, before flows and screens are drawn, because that is the cheapest point at which to discover you were wrong.

People rarely work exactly the way they describe their work. A process that sounds simple in an interview can reveal several hidden steps when you see it in practice. Users switch between tools, keep information in personal notes, repeat tasks by hand and invent workarounds when a product does not support what they need. These behaviors are easy to miss when research happens away from the real environment.

Take a leasing agent who says, in an interview, that they confirm viewings in the system. Sit with them for an hour and you may see them also text each tenant from their own phone, because they do not trust the automated reminder. That second step is invisible in the interview and obvious in context. It is also exactly the kind of detail that decides whether a new product replaces the old habit or gets ignored.

Each research method answers a different question. Contextual inquiry is not a replacement for the others; it fills the gap they leave.

A common sequence is contextual inquiry first to understand the work, a prototype to propose a better way, then usability tests to check the proposal.

The method earns its time when the work is complex and the cost of misunderstanding it is high. It is especially useful when:

• You are building for a professional workflow, such as procurement, property management, operations or finance.
• Your product will replace spreadsheets, email threads or a patchwork of tools.
• An existing product has lower adoption than expected and nobody can say why.
• The people who buy the software are not the people who use it every day.
• The work involves handoffs between roles, teams or companies.

Skip it, or keep it light, when the product follows a familiar consumer pattern, when you need numbers rather than understanding, or when you cannot reach the setting at all. In that last case, a remote session over screen share, with the participant doing real work on their own machine, gets you much of the way there.

A session is a structured observation, not an open-ended chat. This is the sequence we follow:

1. Pick the focus. One workflow and one question, for example: how do buyers compare quotes from several suppliers?
2. Recruit the people who do the work. A handful of participants, often four to eight, across the roles involved. Include someone new to the job and someone who has done it for years.
3. Schedule around real work. Ask participants to save a genuine task for the session rather than demonstrating a made-up one.
4. Open with a short briefing. Ten to fifteen minutes: explain the purpose, agree how notes or recordings will be handled, and make clear they are the expert.
5. Observe, then ask. Let them work for sixty to ninety minutes. Ask at natural pauses, and note what they do as well as what they say.
6. Interpret together. Play back what you think you saw and let them correct you. Corrections are the most valuable part of the session.
7. Wrap up. Ask what you missed, and with permission collect copies of the documents, templates and spreadsheets they used.
8. Debrief within a day. Write up the session while memory is fresh, before the next one blurs it.

Two researchers per session work well: one leads the conversation, the other takes notes. More than two people in the room starts to change the behavior you came to see.

Use these as prompts, not a script. The best questions come from what you just watched.

Opening questions

• What are you working on today, and what would a good outcome look like?
• Where does this task usually start for you?
• Who else is involved before or after you?

While they work

• What are you looking for right now?
• How did you decide on that option?
• What would happen if you skipped this step?
• Where does this information come from?

At a breakdown or workaround

• I noticed you switched to another tool there. What does it give you?
• How often does this happen?
• What do you do when this goes wrong?
• Tell me about the last time this caused a problem.

Closing questions

• Was today typical? What usually goes differently?
• What did we not see that matters?
• If one part of this disappeared tomorrow, which would you miss least?

Avoid leading questions such as "Would it help if this were automatic?" Ask about the last real occurrence of something, not what usually happens, because specific memories are more reliable than general ones.

The most valuable insights are not always the biggest problems. Sometimes they are small behaviors that point to a larger opportunity. Watch for:

• Workarounds: spreadsheets, sticky notes, copied text and personal reminders that fill gaps in the official tools.
• Breakdowns: moments where the work stops because information is missing, wrong or in the wrong place.
• Artifacts: the documents, forms and templates people rely on, and what they write on them.
• Handoffs: every point where work passes to another person, and what gets lost on the way.
• Interruptions: how often people are pulled away, and how they find their place again.
• Hesitation: pauses, double-checks and moments of "let me just make sure".

Pay attention to what users do, not only what they say. A small workaround repeated across a team can become an important product requirement.

Observation alone is not enough. Within a day or two of each session, hold an interpretation session with the team: read the notes aloud, and write each distinct observation on its own card or sticky note.

Once you have several sessions, group the notes from the bottom up into an affinity diagram, letting themes emerge rather than sorting into categories you chose in advance. Simple work models help too: a flow model of who hands what to whom, a sequence model of the steps and what triggers them, and an artifact model of the documents people use.

Then write insights in a form the team can design around. Instead of "users find this difficult", aim for: when a situation occurs, this role does this workaround because of this reason, which costs this outcome. For example: when supplier quotes arrive in different formats, buyers retype line items into a spreadsheet because the system cannot compare them, which delays every decision.

Finally, separate individual preferences from recurring problems. Something one participant does is a hypothesis. Something most participants do, in different ways, is a pattern.

Research only matters when it changes what gets built. We map each insight to one of a few decisions:

• Build first: problems that recur across participants and block the core outcome.
• Design around: workarounds that reveal what users value, such as the flexibility of a spreadsheet, which the new product must keep.
• Automate or default: manual steps that every participant repeats in the same way.
• Organize: the order and grouping users already work in, which becomes the information architecture.
• Cut: features requested in interviews that never came up in observed work.
• Test next: assumptions the sessions could not settle.

On a procurement platform such as CollectiveSpend, which covers sourcing, multi-supplier RFQs, purchase orders and approvals with AED pricing and local suppliers, the decisions that matter most live in exactly these details: how quotes get compared, who approves what, and where a purchase stalls. They only become clear when you watch the work.

The "test next" list feeds straight into a prototype. Our playbook on rapid prototyping for startups shows how findings become a clickable flow quickly, and our guide to validating a SaaS idea covers what to do when the evidence is still thin. This research is also where our product design services start on most projects.

Most failed sessions fail in predictable ways:

• Turning the session into an interview, with the participant talking about work instead of doing it.
• Asking leading questions that invite the participant to agree with your idea.
• Studying the manager who describes the process rather than the person who performs it.
• Bringing too many observers, which makes people perform rather than work.
• Waiting a week to debrief, by which time the details have faded.
• Treating one participant's habit as a requirement for everyone.
• Ending with a report nobody reads instead of decisions the team acts on.

Good product decisions start with understanding the people behind them. Contextual inquiry gives teams a close look at how a product will fit into real workflows, environments and everyday decisions. When we understand the context, we can design with greater clarity, and that usually leads to products that feel less complicated, more useful and easier to adopt.

If you already have research notes and want to see them turned into a working flow, you can request a free clickable prototype. We review the request, agree the scope and deliver it within 48 hours.