Conducting Contextual Enquiry (or Site Visits)

To do good design, you need to understand the relevant parts of your users’ lives. One of the most powerful ways of gathering this information is by talking to those users. Contextual enquiry (or site visits) is a great way of doing this.

This short video will walk you through the process.

You can (and should) get good data from secondary sources such as analytics, marketing intelligence, customer support staff, third-party reports, and the like. But for genuine insights, you can’t beat spending time with users, in their own environments, watching them do the things your product or service is going to support.

One of my favourite quotations is from Sun Tzu: “Time spend in reconnaissance is seldom wasted.” You can often trace the fundamentally good things about design solutions to simple observations you made during field research. For example, a function that’s given prominence in the UI may have been identified as important early in your research.

Formally, the method we’re talking about here is “contextual enquiry” (or “inquiry” depending on your neck of the woods.) I usually just refer to “site visits” or “user research,” as these are terms my clients relate to. And we UX’ers are the enemies of jargon, right?

Really, you should always have your user research hat on. I’ve often gathered really useful information from opportunistic circumstances. For example, when visiting a workplace you might strike up a conversation with a person who can provide valuable insights. I believe you should always be willing to abandon or adapt your plans to take advantage of changed circumstances.

So while we’ll talk about an ideal or typical approach here, let’s not forget that we should always be willing to ride the waves.

Let’s think about our contextual analysis in 3 parts:

1. Identify the people (users) to visit and schedule visits
2. Carry out the visits
3. Analyse the data

Who to visit?

You need to visit the right people, and you need to visit enough people. You also need to constrain this activity, because it will become time-consuming and you may be swamped by a flood of data.

So, how many people? Figure it like this: You need to see at least 2 people from each significantly different user groups. That’s easy to say, but let’s take an example. For example, if you were looking at travel website, you might figure that you need to get input from:

• people who always book their travel online
• people who tend to use offline services

If we see 2 people from each, that’s a total of 4 people. My personal preference would be to beef this up to 6, just because experience has shown that 6 is a good number and gives you a degree of confidence that you’re getting a good understanding. Within that 6, you’d try to get a spread of other characteristics – for example a mix of older and younger people, and an approximate gender balance.

On more complex projects, the number of people to visit can get very big very quickly. For example, a project in the justice system might mean visiting prisoners, young offenders, police, court staff, judges, health professionals and more.

Where possible, limit your site visits to around 12 people. Certainly if you go above 20 you’re going to have a very large data set to deal with.

You’ll also have to consider budget. As a rule of thumb, visiting 6 people will probably take 3 days of planning, 3 days for the visits, and 3 days of analysis – say 2 weeks of effort. While that’s likely to be money well spent, it’s a considerable undertaking. Adding more users will increase this cost.

Scheduling

Don’t underestimate the effort involved in scheduling. You’ll need to contact each user and set a time that you can visit them. People may be reluctant to commit too much time, so you need to clearly communicate the benefit of what you’re doing, and undertake to limit their time commitment.

In general, I find that a one-hour visit is likely to be acceptable, particularly if people understand that what you are doing will make their life (or the life of their peers) better when you design and implement the new system or product.

When scheduling, you should communicate (typically by email) to let users know what to expect. Key elements are that you want to see them in their regular environment (at their desk or office or workbench in a workplace, in their home for home-based products, and so on).

Another important aspect of scheduling is that you probably want to see people on a typical or busy day, whereas people’s natural inclination will be to see you on a quite (and perhaps unrepresentative) day. Try to communicate how important it is to see them on a typical day.

A team of two

I like to have another person with me when conducting site visits. This may be a fellow UX’er, or it may be a member of the development team, or a client (and there’s nothing to stop you mixing-and-matching so that several people get to go on site.) Having another person means that you can discuss together what you observed, and what might be the implications. It also means that you have two sets of notes (ideally) and are less likely to miss things. It also means that several people have the opportunity to get an invaluable view of the “real world,” as well as learning how to conduct site visits for future projects.

Avoid cramming

I try to limit visits to 2 per day. This may sound like a light workload, but it’s really important to have time to write up your notes, and consider and discuss what you’ve learned, after each visit.

On the other hand, there are times when you have to cram more visits in, so you need a degree of flexibility. Just keep in mind that the quality of your effort deteriorates as you over-pack your schedule.

Conducting a visit

Before you go on site visits, there are a few things you need to prepare. If you are audio- or video-recording, then you will need to make sure your equipment is fully functional. You’ll also need to ensure that you have appropriate forms that explain how recordings will be used, and which you interviewees can sign to indicate their acceptance of the conditions. You should also be prepared to abandon recording if your interviewee is uncomfortable or reluctant.

Recording adds a level of complexity; for most of my work I do not record, but this really depends on your work domain and whether you need to record to communicate findings to others.

I like to have a very short script explaining why we are conducting a site visit. I read the script to interviewees at the earliest opportunity at the start of the session. Some people don’t like using scripts, and they can feel a bit stilted. On the upside, they ensure that you make a clear statement of the purpose of your visit, and this can serve to redirect sessions that are going off-track (you can refer back to your introduction.) The script also enables you to make any appropriate remarks about confidentiality or anonymity.

I like to offer people the highest degree of anonymity. For example, I always undertake not to use people’s names in reports or documents. However, I also have to alert people in some cases that it may be possible for others to deduce who made particular comments. It’s also the case that some people specifically don’t want anonymity, and want their voices to be heard clearly, and perhaps acknowledged. You’ll need to make your own decisions as to how to deal with these factors.

It’s also a good idea, in a work situation, to point out that the site visit is not an evaluation of the person’s performance, nor a review of their position or role.

Once you’ve got any paperwork, permissions and formalities out of the way, you’re can get down to the nitty-gritty. Firstly, make sure you’re in the user’s normal context. Despite your best efforts in initial communication, you’ll often find that when you visit, people may have booked a meeting room or set aside a special area. You will need to gently but firmly explain that you want to meet with the person in their regular environment so they can show you, not tell you, what they do.

The importance of detailed note-taking

It’s really important to take detailed notes. I use pen and paper. Some people I know have tried to use tablets or laptops. The problem with this, in my experience, is that it tends to distance you from your participants. But if you can make it work, go for it. I take copious notes – you never know what details are going to be important, but you can be absolutely sure that you won’t be able to create sufficient details from memory. You may be able to do so from audio/video recording, but this is inherently inefficient.

I type my notes, as soon as possible after each visit, into a simple document of spreadsheet format. Here’s an example. Each individual item is numbered (so you can always find exactly the source for any statement, comment or observation,) and each item is associated with a particular person (or group if you end up doing a group visit.)

As you can see, the notes are very rough – but this is precisely where the value lies. As you first make these notes, and subsequently review and analyse them, you are making valuable connections between items, and developing an understanding of the “problem space.”

What should the notes contain?

Everything! What you saw, what was said, what was done, what artefacts were used, what interruptions occurred. You want to get a full rich view of the user’s world. Some people are good at doing quick sketches and these can be very useful. I’m too slow at that, so I stick to words.

The “master-apprentice” model

In the book “Contextual Design,” the authors describe a “master-apprentice” model that I’ve always found a useful mindset. When you’re on site, you are visiting a master. The participant, by definition, is the master within their own domain, and you are there to learn from them. If you also communicate this concept to the people you are working with, it helps prevent the situation where you are a colleague attempts to teach a participant the “right” way to do something.

All that data!

You’ll very quickly accumulate a lot of information, and you will need to decide how to handle it. To the greatest possible extent, you need to get key information out of your notes and into the minds of the people you need to work with.

For small amounts of information, you may be able to process it online, simply “eye-balling” it in a spreadsheet and sorting it into groups to identify important themes, issues and opportunities.

I generally do a card-sort – printing out each notation on an index card, and grouping them (preferably with at least one other person) to build up a sensible and manageable dataset. This may seem like a lot of effort, but it really is great way to come to grips with a lot of information.

For very large data sets, you can use programs such as nVivo or Dedoose, but be aware that these tend to have a reasonably steep learning curve, and demand a certain commitment of time and effort.

You may want to create personas (fictitious, representative users) based on your observations of how people behaved and what characteristics had an influence on how they interacted with the product or service.

Stories also provide a strong and simple way of describing typical actions and interactions. These may be simple scenarios, or fully elaborated stories; you will need to consider what best suits your needs.

Whatever approach you take, make sure that you consider the purpose of the materials you prepare – for example, scenarios will help in conducting participatory design, personas will help designers, and the client, agree on the target audience for various features of the product or service.

A service map or blueprint may be useful for working on more elaborate problems.

The main thing is to ensure that the data you gathered is mined for your immediate needs, and also retained for possible future re-use.

However you end up working, the key thing is getting out and spending time with users. Provided you do this with an enquiring and flexible mind, you will reap many benefits, and your designs will be all the better for your effort.