Contextual inquiry: when and how to use it for user research

As well as usability tests, another highly effective method is available for directly observing users and their interaction with applications: participant observation, also known as contextual inquiry or sometimes also called on-site study. This doesn’t involve setting people tasks like in a usability test. Instead, you visit people at home or their workplace and talk to them.

What does participant observation do?

The basic idea behind the usability test and participant observation is the same: you watch real users doing what they actually do. That means that participant observation is not simply an interview. Observation is actually at the heart of it – you watch users while they do everyday tasks.

The advantages of participant observation are:

• observe actual use
• see entire usage situation and context of use
• gain an understanding of users’ exact behavior
• get to know other tools/applications used
• find out which other users might be involved when and why
• no need for a test object (i.e. no prototypes, no application, but investigation of existing application is possible)

Unlike in an in-depth interview, you can tell what the user is doing straight away during participant observation/contextual inquiry. This makes this form of user research easier for the participant as well as for you, the researcher. Of course, you also interview the user during participant observation. But that’s just a secondary part of it – the key aspect is the user’s actual work. That’s why UX experts like this method so much: it lets us see what people really do, rather than being dependent on people remembering what they’ve done and correctly reporting it to us.

During participant observation, the subject explains to you exactly how they go about things.

Partying with users? A definition of participant observation

The participant observation method comes from ethnology. Originally, researchers went to live with an indigenous tribe, for example, and took part in their everyday activities. In the late 19th century, for instance, ethnologists made bows and arrows, went hunting and celebrated festivals with Native Americans. We UX experts rarely go partying with our subjects. Usually, the context is purely professional. But it is feasible – perhaps if you want to develop an app allowing users to take photos and videos and write reviews and so on of parties, concerts and similar events.

The different terms often get confused – if you’re speaking to colleagues or clients, it’s always worth your while clarifying what is meant by the term in question.

Ethnographic study or field observation is actually terms for methods originating from ethnography (to make it even more complicated, they sometimes come from anthropology, too, which is a bit more broadly defined than ethnography or ethnology). But as has already been mentioned, in UX, these kinds of clear distinctions are never really made, so let’s save ourselves the hard work of overly-detailed definitions.

The important thing is that the terms participant observation, contextual inquiry, and on-site study or on-site observation usually mean the same thing.

Some colleagues also make a distinction between these methods and shadowing. In shadowing, as the user researcher, I am the user’s shadow. This means I watch them while they perform everyday tasks, as in participant observation. However, strictly speaking, shadowing involves no interaction with the user. That means that UX specialists like us only observe what is going on, and do not ask any questions.

Similar tasks are performed in a diary study: in this case, you allow the user to record what they do in their day-to-day work by themselves. That means you don’t need to follow anyone around – but there’s more work involved for you in preparing and following up these kinds of diary studies. For more on this method, see Diary studies: a practical guide.

When is participant observation worthwhile?

Participant observation/contextual inquiry is always worthwhile whenever you want to find out more about users. First and foremost, this is the case in the early stages of a project. So, for example, if you have an idea for an application but don’t know whether users would have any need for it. Or if you’d like to know how users currently solve the problem your application aims to fix. Or if you’re interested in which competing applications or alternative approaches people use.

Three examples of worthwhile uses for a contextual inquiry:

• You want to develop an app that music fans can use to find and contact each other at major rock concerts or outdoor music events. So you go with a couple of music fans to the next outdoor event. You watch exactly what they do to communicate with their friends. Do they agree to meet at a specific bar or outside a specific tent? When do they send each other WhatsApp or text messages? When do they make telephone calls or send voice messages? Which other forms of contact do they use? How many friends do they communicate with during the event and why?
• You want to improve the kitchen planning tool on a furniture design website. So, you visit a few people who are currently looking to buy a new kitchen. You watch how they research online and how they measure up their kitchen. How they might use boxes and tablecloths to work out how it might look if certain pieces of furniture were stood against the wall at certain heights. You might even go with them to the furniture store.
• You want to find out which new functions are the most promising for an existing fitness tracker and the accompanying app. So, you go running or cycling with a couple of sports enthusiasts. How do they prepare for their run or their trip? How do they record it? You watch how and when they contact other people, and if and how they take photos during the activity. You note which physical parameters they measure and assess, and which landmarks they document along the way.

If you want to develop an app for music festivals, you should go to festivals with representative members of your target audience.

Benefits of participant observation compared to usability tests and interviews

In the three examples above, usability tests would barely help you achieve what you want: in the case of the app for people attending concerts, there’s nothing to test yet, and a test in the usability lab would have little point to it. In the case of the kitchen planning tool, you can indeed find out how to optimize the existing online kitchen planning tool – but a test won’t tell you what else the user does or other needs and solutions they have. And in the case of the fitness tracker, you can only use a usability test to improve the existing application. New ideas would only come up by chance. That’s why contextual inquiry is so valuable in these situations.
The argument ‘then let’s just ask the users!’ often crops up.

It’s true that this is much better than coming up with new ideas just based on your gut feeling. However, user interviews and focus groups are only of limited use for obtaining new ideas and finding out how people actually behave. This is because our answers are filtered in two ways when we are asked questions:

1. We filter through our own memory.
   We don’t notice everything, and we don’t always think of everything. Often, we can’t correctly replicate processes we perform very frequently – we simply reel them off automatically. When it comes to things that took place a little while ago, we can only reproduce them imperfectly.
2. We filter through our conscious or unconscious choice.
   Some details seem unimportant to us, so we don’t say anything about them. Only a highly skillful interviewer who knows the subject matter very well can counteract this, at least in part. And there are other things that we don’t say because they embarrass us or because we get the feeling that they show us in an unflattering light. This choice may be conscious or unconscious.

Who to observe? How to recruit? What incentives to offer?

As in all user research activities, try to recruit subjects for participant observation who match your target audience as closely as possible. When you’re developing new product ideas, you might not have any contact with your target audience. That’s why it makes sense to visit trade fairs, conferences or other events that appeal to your target audience or to get in touch with them online on forums and user groups. There, you can also cautiously(!) advertise your idea and recruit subjects for participant observation. Before you blurt out your idea, spend a few days watching what users on the forum are talking about, and what the tone is like. Look at how you can get involved to emphasize the benefit for users.

You can always make life easier for yourself when recruiting by outsourcing recruitment – it’s quicker and often more affordable than doing it yourself.

When it comes to incentives (paying subjects), money isn’t always the best solution. It’s often better to offer users something that has to do with the subject matter in question. You might you have your own products that you can give them. Alternatively, you could give away vouchers for products or services that relate to the topic at hand. And remember: for many participants, witnessing the development of an exciting new product is a real draw in itself. They want to be heard and contribute their opinion – and they like to be a step ahead of other people.

If the subjects know in advance that you’re going to come to their workplace, almost all of them will tidy up first. That’s a shame because you actually want to get to know their day-to-day life. Asking them in advance not to tidy up isn’t much use either: this only serves to remind some of them that they could tidy up, and then they go and do it anyway. The best solution is to have a one-to-one chat before the event and mention that they shouldn’t prepare or tidy up and that you are interested in an authentic working environment.

One last point on preparation: some subjects bring a colleague, co-worker or boss with them. This might be because they want to help you, thinking that they can’t answer all the questions. Or it might be because they’re unsure, or because they want to get other people involved. Try to get your subjects to turn up alone. After all, you’re not interested in complete answers to your questions. You want to observe everyday life, so having more than one subject can be quite disruptive. There is one exception: if the work that you’re interested in is done by multiple people working together on a day-to-day basis. So, for instance, if you’re observing the use of a large machine that three people always work on together, there should also be three people present during your participant observation.

What is the level of effort involved in participant observation?

As in usability tests, the effort involved in contextual inquiry is based first and foremost on how many subjects you have. There are no strict specifications: even with three subjects, you’ll gather important information. As in a usability test, I personally would plan for at least five subjects. This gives you a clear idea of whether some approaches, requirements, and preferences are special cases or whether they occur among multiple users.

If your target audience is very diverse, it’s worth your while recruiting many more subjects.

There’s a helpful rule of thumb for the implementation period for participant observation: one to two hours per subject is usually sufficient – unless you have very specific requirements. In our examples above, two hours would be enough for researching the process of kitchen buying and undertaking fitness research. However, for the festival visit, you would need to invest a day for each subject – although that’s certainly an event where there’d be no shortage of fun involved for you, too.

I take a day for preparation – you need to clarify the issue, write your guide, initiate or implement recruitment, and arrange scheduling.

For the follow-up, I’d set aside half a day per subject. That’s how long it takes to look through, compare and document your findings. The more subjects you have, the quicker you’ll get. After all, the same observations will come up and again, and you won’t have to record them in as much detail.

Informing/preparing subjects

NB: before your visit, tell the subjects that they don’t need to prepare. They will often want to know what you’re going to ask. Simply give them a rough outline of the subject matter that will come up, and tell them that the main thing is that they show you their day-to-day work, reminding them that they don’t have to prepare anything at all. It’s also important that they understand that you would like to hold the conversation in the exact place that they perform the activity. In the working environment, that means asking if you can come to their desk or into their workshop. After all, an interview in a conference room is exactly that: an interview, not participant observation.

If the matter at hand is purely a software product, then if needs must, subjects can show you their work on a laptop in the conference room. However, in this case, they should use their own laptop that they usually work on. And in these instances, I always ask whether I can see their workplace afterward. It’s a really worthwhile thing to do, as it enables you to see the environment. You can see the Post-its on the monitor. The notebook by the keyboard. The folders and manuals on the shelves. Hints as to the office’s culture, with cartoons or motivating slogans on the wall. You find out whether the person sits alone in the office. Whether it’s peaceful there, or more lively. This is all important information for us as user researchers.

If the subjects know in advance that you’re going to come to their workplace, almost all of them will tidy up first. That’s a shame because you actually want to get to know their real day-to-day life. Asking them in advance not to tidy up isn’t much use either. This only serves to remind some of them that they could tidy up, and then they go and do it anyway. The best solution is to have a one-to-one chat before the event and mention that they shouldn’t prepare or tidy up and that you are interested in an authentic working environment. If you work with a recruitment expert like TestingTime, your colleagues there ensure that the subjects are well-briefed.

During participant observation, you go where the work you’re interested in takes place.

Here’s another thing you should explain to the subject in advance: you’d like to speak to them alone. Some would like to have a colleague, co-worker or boss with them. This might be because they want to help you, thinking that they can’t answer all the questions. Or it might be because they’re unsure, or because they want to get other people involved. But try to get your subjects to turn up alone. After all, you’re not interested in complete answers to your questions. You want to observe everyday life: more than one subject can be quite disruptive. There is one exception: if the work that you’re interested in is done by multiple people working together on a day-to-day basis. So, for instance, if you’re observing the use of a large machine that three people always work on together, there should also be three people present during your participant observation.

Write a guide

Of course, you can simply visit your users and have a chat with them. That’s better than having no contact with your users at all. But if you really want to take the work seriously, you need a guide for your participant observation.

Your research questions form the basis of this: what do you actually want to find out? What findings do you hope to emerge from the investigation? Research hypotheses are a useful tool for formulating these questions.

If you know what you want to get out of it, you can set about structuring your visit to the user. The guide follows the workflow of the visit as I have depicted it in the following section. All you need to do is write down key points and perhaps formulate the tasks. Unlike in usability tests, I don’t read the questions out in the contextual inquiry. Instead, I say them in my own words. After all, every visit is different anyway, so you can get straight into the specifics.

Conduct the observation

Usually, your visit to the subject follows this template:

1. Greeting, explaining the procedure, warm-up questions (warm-up/icebreaker)
2. Actual observation
3. Closing questions, goodbye

The first part is intended to relax your subjects. You want to create a relaxed atmosphere where they can tell you in confidence about their day-to-day procedures. Practically every subject is a little nervous at the start, even if they don’t show it. Asking how long they’ve worked at the company, how they get along with colleagues or what training they have had comes across as very natural. It’s even better if something personal comes to mind. For example, if you see a photo of a dog at their workstation, you can ask about it. Or you could ask about the football team whose scarf is hanging on the wall.

But you shouldn’t spend too much time warming up: it shouldn’t take any longer than five minutes. If you’d like to find out demographic details (age, family situation, etc.), it’s better to do that in advance – then you don’t need to take up time for this during the conversation in person.

The main section involves getting the user to demonstrate things as soon as possible. You’re not conducting an interview. Instead, you want to see what the user does. Ask them to complete a specific task. They should explain every single step to you clearly.

Ideally, you should come up with three to six tasks for the user to show you. These should follow a logical sequence – for instance, if the subject needs to log into a system to perform a task, they should log in first, then demonstrate the next step. This prevents you and the subject from getting your wires crossed, and it puts the subject in a slightly more natural situation. This means that they will behave more as if you weren’t looking over their shoulder.

At the end of the observation, you should always schedule an extra ten minutes to ask the user additional questions. If you don’t do this, and they have another appointment, say, you might not be able to ask them any further questions. And finally, you say goodbye and thank them for their time. You can briefly touch on what you talked about in the warm-up. So, send best wishes to their pet or keep your fingers crossed for their football team’s next match.

After each conversation, you decide whether the guide needs to be adapted. Ideally, this shouldn’t be the case, as all observations should be comparable. But if you notice that some tasks were not understood or the user did not perform some tasks at all, you should avoid asking the next subjects the same questions.

Student-teacher principle

What the usability test is to ‘thinking out loud’, the contextual inquiry is to the ‘student-teacher principle’. This method is the best way of finding out what’s going on in the subject’s head and how they work. It’s important that you explain this technique to them well at the beginning.

In my experience, the best time to give this explanation is when the subject is about to perform the first task. If you do it during the introduction, most subjects have already forgotten it by the time it comes to the tasks.

You should explain the principle a bit like this: imagine I am your student and you are my teacher. I have no idea how people do this task and you want to explain it to me so I could do it myself tomorrow. So, show me one step after the other and show me everything I need to know. I will ask questions throughout this process. That way, I can be sure that I’m understanding everything correctly.

This is the easiest way to get subjects to actually demonstrate tasks to you. Sometimes the subjects will slip into an abstract mode, where they’ll say things like ‘then I’d click here’. If that happens, simply remind them that you’re their student and ask them to show you what they’re doing, because that’s the best way for you to understand.

The student-teacher principle in action: have the subject explain every step.

Taking accurate notes and creating proper documentation

I always write down the research questions again in the guide: after all, you should always keep them at the back of your mind. That helps you avoid spending your valuable time with the subject on topics that aren’t that important.

Ideally, two of you should attend the participant observation. One person leads the conversation, while the other stays in the background and takes notes. Their involvement in the conversation should cease after the greeting and they should not ask any questions during the observation. This allows the subject to focus entirely on the main speaker and talk to them. This almost always ends in better results and is easier for the subject, too. At the end, the main speaker can ask their colleague who’s been taking notes whether there’s anything else they’d like to know.

In most cases, taking notes by hand or on a tablet is sufficient. I don’t really like laptops for recording what’s going on. The tapping of the keys interrupts the conversation and you seem a bit more formal than if you’re only working with a pen and paper. That isn’t ideal for the relaxed atmosphere of the observation.

Making an audio recording of the conversation is an option, particularly if you’re alone and don’t have anyone taking notes. A simple smartphone app will usually do unless you’re on a noisy factory floor.

If complex processes are involved, it’s a good idea to take photos. And if you want to document the working environment (for colleagues who aren’t there, too), a couple of photos are a good idea. Most subjects don’t mind if you snap one or two photos.
However, video recordings are very rare in a contextual inquiry. Almost all subjects are self-conscious about them, and evaluating video is also very time-consuming. Finally, in businesses, it is often quite difficult to get permission for video recording. In my experience, it’s easier to handle photos. Whether it’s photos or video – if these recordings are crucial for you, you should establish before your visit whether this is ok with your subjects.

It’s less complicated for audio. All you need to do is bring along a declaration of consent for them to sign. In this declaration, you should provide any necessary information about data protection in accordance with the GDPR (for EU citizens), making it clear to the subject that the recording is only for evaluation purposes and will not be disclosed to anyone.

After the conversation, you should speak to the person taking notes right away – not when you’re back at the office or even the next day. Go through everything again immediately, comparing your impressions and the most important findings while everything is still fresh in your memory.

Using a notepad instead of a laptop lets you be more mobile, and the person you’re talking to feels less closely observed.

Dealing with unexpected and tricky situations

For me, the exciting thing about participant observation is that you can never plan everything. You will often experience things you haven’t expected. Let’s say that the subject takes you into a laboratory that looks like the kind of thing you only thought existed in science fiction films. He works with extremely expensive hi-tech equipment that has several large, colorful screens. And then he takes a worn-out old felt-tip pen from his pocket to mark the fill level on his sophisticated device. The product designers apparently hadn’t provided a way for this information that’s so important to the subject to be presented in a more elegant way.

These observations are surprising, and they are the reason why contextual inquiry is so worthwhile. However, you sometimes also get into tricky situations. It’s obvious that you must never endanger your own health or that of the subject. If you visit a building site and your subject tells you that they don’t wear a helmet and safety shoes, even though they’re required to, this may be important information. However, you shouldn’t go to the building site in the same state. Instead, you should try to get the subject to supply the right equipment for both of you. If you don’t manage it, you might need to break off the observation.

But things like that only happen very rarely – I’ve personally never experienced anything like that, and don’t know anyone else who has. Often, the opposite occurs: the subject leads you into a wonderful empty conference room. Not into the lab, or onto the construction site, or to their desk. This may happen whether or not you’ve made it clear in advance that you want to conduct the conversation in their workplace. Try to convince your subject to go there anyway.

If you don’t manage it, ask if you can at least see their workplace at the end. Try to replicate the work situation as authentically as possible with your subject. Use a pen and paper to help, or even tables and chairs. Anything goes, as long as it might help you understand how the subject works. Take charge of everything: explain to the subject that you need everything to help you picture things. You don’t need to tell them that they also need it to help them remember as much as they can correctly.

For participant observation, conference rooms should always be an emergency solution, nothing more. Always try to conduct the conversation at the subject’s workplace.

If more subjects turn up than you expected, don’t send them away immediately. That might annoy both them and the person you’re speaking to. Instead, find out why their colleagues are there. If they usually work on the tasks alone, ask them to demonstrate this individually. The others should only watch, and not pass comment or talk throughout. The student-teacher principle comes in handy here again: let one person explain each step to you. To avoid being pushed for time, have the subjects demonstrate one task each instead of having several subjects show you the same one.

Evaluating and presenting findings

The traditional outcome of participant observation is a set of notes. The problem is that practically nobody reads them. Notes are long and unstructured, and if you’ve visited five or more subjects, it also takes far too long to read all of them.

If you’ve taken photos, this is a good basis for preparing things in a way that is easy for your colleagues to digest. Take these photos, put them in a (PowerPoint) presentation and write a few key points next to each one. What was noteworthy about your visit to this subject? What did you learn?

If you’ve taken photos, they can make your findings easier to digest. However, you can also prepare your findings in a brief and reader-friendly manner without using photos.

Turn back to your research questions as a summary: write each one on a slide and put the answers in keywords below. Is there a clear answer across all the visits? Or did the subjects take different approaches?

Which questions could not be answered? Do you have any idea of how you might otherwise find the answers? Do you need to speak to other people? Or do you need to use another research method such as diary studies or evaluating access numbers/analytics?

And finally, it’s always good to describe surprising facts or funny events. I like to put these at the beginning of the presentation to attract listeners’ or readers’ attention.
It’s best if you then actually give the presentation to colleagues and stakeholders. If you just send it to them, information gets lost, and what’s more – who actually reads anything they get by email?

A streamlined and effective alternative to creating a presentation is presenting the findings in a joint team workshop and using this to come up with the next steps.

In this type of workshop, you use the information you recorded as a reminder and report back to the team about the individual visits. The others take notes and write all the interesting observations down on Post-its. You then gather them together and put them on the wall in clusters. It’s even more efficient if you make ‘how might we’ notes instead of the observations. That means you formulate a question beginning with ‘how might we?’ from every observation. For instance, if the observation is something like: the subject marks the fill level on the device using a felt-tip pen. You can turn that into this ‘how might we’ note: how might we show the fill level to the user?

This kind of workshop doesn’t just allow you to present the findings from the participant observation to the team. It also lets you develop questions from the findings which are as specific as possible and will help you continue to develop the product.

Let people listening to your presentation write on Post-its, too – that makes them active listeners, and you’ll have your documentation ready at the end.

Benefits and drawbacks of contextual inquiry compared to (on-site) usability tests

Conclusion

Participation observation/contextual inquiry is an indispensable method when redesigning, overhauling or expanding applications. Unlike in usability tests, you don’t simulate anything for the user. Instead, you learn a great deal about their day-to-day life, practical problems, and actual habits when using applications and devices. And unlike in interviews, no information is lost because the user has forgotten it or believes it to be unimportant.

Although the participant observation method is a little more time-consuming, it’s very worthwhile. What’s more: it’s much easier to do than a usability test, and for most people, much more fun.