We have various ways to understand people. We talk to get to know them, look at how they behave in different circumstances, notice their reactions. If it is a romantic relationship, some suggest the best way to get to know each other is to travel together. You might act differently on a date whereas you cannot act all the time on a trip. You have no place to hide your happiness or frustration.
Let’s think this way in a product relationship between the product teams and the user. As a part of their quest to blend user experiences, product teams want to understand their users, learn their pains, concerns, issues, and how they operate with or without their product.
In this case. the user interviews are similar to dates, where the product team meets the user in a new environment and tries to like each other. If you want to know how your product is a part of your user’s day-to-day life, contextual inquiry is traveling with your user.
Contextual inquiry is a discovery method where the product teams meet the user at the location where the user encounters the problem and needs a solution. The product team is able to make observations and interview the user on their experience during these sessions. It helps them understand the users and their tasks, frequency of the problems they face and how they handle them.
To get prepared, the product teams might revisit their UX interview notes around the problem and user segments. For every user group the product team wants to discover, there should be at least 5–6 users to be visited. The researchers might expect to spend at least 1–2 hours on each visit and be flexible. You will probably spend 10–15 minutes on introduction and brief, 30–60 minutes on observation (based on the flow you want to observe) and 15–30 minutes on questions and wrap up.
As is the nature of all UX discovery, the researcher should not put any pressure on the user. The user should be aware that the researcher is not here to judge. The product researcher is interested in learning and observation.
The best practice would be to frame the session with the user and establish the observation boundaries with them. Based on the boundaries set, a contextual inquiry becomes an active or passive inquiry. After you frame your visit via explaining the research purpose, the expectations, and the possible timeline, you might set the boundaries with the example questions below:
There are two types of contextual inquiry: active and passive.
The active inquiry is the type where the researcher and the user are in active communication during the observation. The researcher is free to interrupt. On the contrary, the researcher doesn’t interrupt the user during the observation in the passive inquiry.
During the observation, the researcher would aim to understand the steps of the user workflows, note the user’s unconscious habits, and take notes. If there is any confusion, the researcher asks questions to clarify them. Observation boundaries are also important because the researcher should know when the user wouldn’t like being interrupted.
If the user has a workflow that needs their full focus or is working on a task under pressure, you might prefer applying passive enquiry. You wouldn’t like to pop up and ask questions while the user is talking to their customers. If the user is in a more relaxed environment and able to do their task while talking to you, you might clarify any actions you observe at that time.
While noting the workflow, the researcher should be aware of external influences. We tend to imagine our products in a simpler environment. Real life is complex. Contextual inquiry gives you a perspective that you can not get from regular user interviews.
Action speaks louder than words. That’s true. However, as a part of contextual inquiry wrap-up, the researcher should summarize their observations and confirm them from the user. It will help to prevent any false perceptions.
When the researcher goes back to their office, they need to prepare their results. Like all UX discoveries, the product team shouldn’t fall into the trap of confirmation bias. The data collected from the contextual inquiry is limited with the number of users they observed. It would be dangerous to assume their observations apply to all users.
As a qualitative method, contextual enquiry is a useful tool to establish the base. As a follow-up, the product team can prove/disprove their hypothesis from contextual inquiry with quantitative methods like comparing with your analytics data, or measuring your customer effort score using Wizard of Oz.
Contextual inquiry requires more time commitment from the product teams. A contextual inquiry’s budget depends on the time investment the product team wants to make. The sessions are not staged, so it’s hard to predict when the customer problem that you are interested in is going to happen. You may need to spend hours before you observe.
Effective use of time is seen as one of the drawbacks of contextual inquiry. I am a true believer that no time is wasted if you spend it with the user. You might discover valuable insights from the user’s problem space in that duration.
Another challenge around the contextual inquiry is recruiting users for this journey. In some cases, finding users to conduct a regular interview might be difficult. Someone to agree with another person to be a shadow on their daily life is challenging.
If you had this difficulty with recruitment, you can always ask help from customer success teams or account managers. As they are in contact with your users more, they would know who will be up for a contextual inquiry meeting. Their close relationships with users might be your icebreaker.
I worked in the product team at a B2B marketplace for pharmacies. The pharmacies were using the platform to trade different products from each other. I worked on several predefined features when I first joined the company. However, I truly understood how pharmacies were interacting with our platform when we had field trips.
When you are in the same environment with the user, it gives you a great understanding for what is happening in their world. In this case, we were trying to understand how they were making the decision to buy from our platform as opposed to other platforms.
My expectation was they would have a stock list, compare websites carefully, and give their orders according to the comparison. However, I realized that pharmacies are making a lot of ad hoc orders.
You might be surprised, but one of the barriers I noticed was the password. When the user wanted to check our platform, they didn’t remember their password and they switched to other websites they use more frequently. They were always in a hurry to use our platform, they had several procurement options, they needed to make a business decision fast, and they needed to give an answer to their patient at the pharmacy. Unfortunately, the data dashboard won’t show you the exhaustion they are facing at that moment or the quick decision point where you are out of their jobs to be done.
In another job, I digitized workflows of the technical service team within a micro-mobility company. The system was only able to log the entrance and the exit of the scooter from a warehouse. I needed to understand how they were currently operating to create a system that logs their actions and use of spare parts.
I became an apprentice for the technical service staff. I made it clear to them that I wasn’t there to inspect their performance and job; I just wanted to learn their steps so that we could develop better tools for them. I sat near the technical service staff and noted any steps they are taking from inspecting the scooter, hypothesizing the broken part, and trying to fix it. As a result, we mapped out different ways that the team members were operating and optimized our app accordingly.
Contextual inquiry is being in the field. Any product would benefit from that, to learn hidden areas in the user experiences they aimed for. Based on the findings of the contextual inquiry, you may enable your team to structure better ideas. That’s why I strongly recommend you not only listen to what users say but look at what they do on their terms too.
Header image source: IconScout
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
