Contextual Inquiry

Contextual inquiry means watching somebody do their real work, in their own environment, with their own data, and asking about it while they do it. It combines observation and interview, and it is the method that most reliably finds the things nobody reports.

Its subject is the work, not the product. A usability test shows how somebody handles a task you invented inside software you chose. Contextual inquiry shows what the job actually involves, which in most B2B settings turns out to span several tools, a spreadsheet, a colleague and a piece of paper.

Why the setting matters

People describe their work as the process is supposed to run. What they do is something else, and the difference lives in the environment.

Workarounds are invisible to the person using them. A spreadsheet maintained alongside your product, a naming convention that encodes something the product cannot store, a screenshot pasted into chat because there is no share link. None of this comes up in an interview, because it has stopped being remarkable.

Interruptions are part of the task. Real work is done in fragments between messages and meetings. A flow that assumes one uninterrupted sitting looks fine in a lab and fails at a desk.

The second screen is part of the interface. So is the printed sheet, the sticky note with the account codes, and the colleague two desks over who knows the answer.

Their data is not your demo data. Volume, messiness and edge cases all show up, and all of them change how the product behaves.

Running one

Ask for real work, scheduled anyway. "Can I watch your next month-end close" beats "can you show me how you use the product", which produces a demonstration rather than the thing itself.

Take the apprentice position. They are the expert demonstrating their craft; you are learning it. That framing makes it natural to ask about what is obvious to them, which is exactly what you need.

Ask in the moment, not after. Why did you copy that into a spreadsheet? What would happen if you skipped this step? Reconstructed afterwards, these answers get tidied.

Follow the effort and the anxiety. Where somebody slows down, double-checks, or says "this is the bit I always get wrong" is where the design problem is.

Do not help. The instinct to show a better way ends the session's usefulness and is the hardest thing to resist.

Record what is around them, with permission. The desk, the screens, the paper, the tools open in other tabs.

What it costs and what it returns

It is the most expensive qualitative method per participant. Sessions run one to two hours, they have to happen when the work happens, and in B2B they require somebody to let you into their day.

What it returns is a picture nothing else provides: the workflow as it exists, the tools it crosses, and the accumulated compensations for everything your product does not do. Four to six sessions per role is normally enough, because each one is dense.

The honest constraint is access. Customer success can usually arrange an interview; arranging two hours at somebody's desk is a different ask, and it is why most teams have never run one.

Getting access, which is the whole problem

In B2B the method fails at the door rather than in the room, so the access strategy matters more than the protocol.

Ask for a scheduled event, not for time. "Can I join your Tuesday reconciliation" is a specific, bounded request. "Can I watch you work sometime" is an open-ended imposition and gets declined politely.

Go through the person who already has the relationship. An implementation consultant or a customer success manager can make the request as part of an existing conversation, where a cold approach from product cannot.

Offer something back. A summary of what you learned about their workflow is genuinely useful to a team that has never had one written down.

Take what you can get. Forty-five minutes of real work beats two hours that never gets scheduled, and a recorded screen share beats nothing.

In practice

A team studying their reporting feature runs four contextual inquiries with finance leads during an actual month-end close.

Nobody uses the reporting screen the way the team expected. Each participant exports to a spreadsheet within the first two minutes, and then does the real work there: adding a column of notes explaining variances, highlighting two rows for the board, and reconciling against a figure that lives in a different system entirely.

Asked about it, every one of them describes this as normal. It had never appeared in an interview, a support ticket or a feature request, because from their side nothing is wrong. The export works.

The finding reframes the roadmap. The product had been treating the report as the output; for the customer it is an input, and the actual deliverable is a short written explanation of what changed. That is what the next version should help produce.

Where teams get it wrong

• Asking for a demonstration. You get the official process, performed.
• Helping. One tip and you are watching your own workflow being followed.
• Only watching the product. The job crosses tools, and the gaps between them are where the pain is.
• A clean demo account. Real volume and real mess change the behaviour you came to see.
• Skipping it because it is expensive. It is, and it is the only method that shows the work rather than the product.