Contextual Enquiry - A Primer

Preparing for Site Visits

Before you race out to meet site users, you must prepare! Think about the materials you'll require, the people who will conduct the visits, and plan to brief yourself and others.

Materials

The minimum requirements are a pen and some paper, but consider which of the following you might also need:

• A script. This is a short, formal statement that you read to participants when you first meet them. It explains the purpose of the visit and provides assurance about the anonymity of the information you'll collect (if you are, in fact, guaranteeing this).
• A demographic questionnaire. This gives you the opportunity to begin building a picture of the people who will use the product, but it the data you obtain will also be useful in you reports back to the project team about the people who will use the product. Demographic information will also help if you're creating personas to represent users during the design phase. The demographic questionnaire is often filled in at the start of the session. Don't ask for personal information that you don't need.
• Consent form. This document outlines the information you'll gather and how it will be used. The person you are visiting signs this to grant you permission to conduct the visit (and to record, if you're doing so). If a subject is reluctant to allow recording, conduct the visit without the recording devices.
• An 'Additional Information' questionnaire. At the end of the site visit, you may want to ask for specific feedback about current applications the person uses, or issues that you may not have the opportunity to observe during the visit.
• Payment. You may need to pay participants, in which case you'll need them to sign a receipt. In some case, such as workplace visits to employees within an organization, it may be appropriate to provide a 'thank-you' gift such as movie tokens, rather than money.
• Video and audio equipment. Some practitioners advocate the use of video, but I avoid it as it involves additional set-up and management, consideration of additional legal and ethical issues, and may make participants ill-at-ease.

Personnel

Conducting site visits doesn't require specialized skills, but the person who conducts the visits should be a good communicator. The interviewer should be capable of putting participants at ease, and be observant and attentive to detail.

It's a good idea to work in pairs for several reasons, which we'll discuss in this section. This approach also provides the opportunity to train a junior staff member, or to have different developers get a taste for "user land".

Conducting the Visits

Each site visit is unique. By structuring all visits in the same way, you can make sure that you get the most out of your contextual enquiry.

Put Users at Ease

Having people watch you work can be an unsettling experience, and participants are likely to feel uncomfortable. Reassure them that you're not there to evaluate their performance, but to learn about their workplace, tasks and issues, and to improve the products they use. Be relaxed and friendly, and honest about what you're trying to achieve.

In my experience, people have generally been very happy to provide information that can help improve their workplace, or the products and tools that they use.

The 'Master-Apprentice' Model

Sometimes it's tempting to show people better ways of doing their work, or using their applications. However, this is not the purpose of a site visit; you are there to learn, not teach.

Think of yourself as an apprentice who is visiting a master to learn about what they do. This model (suggested by Beyer and Holtzblatt) is very effective, and is an accurate representation of the actual relationship between you and the participant.

Ask Questions

To learn about the tasks and issues the user faces, you will need to ask questions. Don't be afraid of appearing foolish or asking 'stupid' questions. Avoid any suggestion of criticism in your questions. For example, rather than "Why didn't you know that would happen?" ask, "Is that what you expected to happen?"

Take Notes and Recordings

After you've completed a few sessions, it can be hard to remember what happened at each one. Good note-taking is vital. If you're recording your visits, consider the recording as a no more than a backup for emergency purposes, because reviewing a recording will add significantly to the amount of time you need to spend in the analysis phase.

If you take hand-written notes, it is important to get them into electronic format as quickly as possible after the visits. If you can afford it, and if your hand-writing is reasonably good, consider paying someone to transcribe your written notes.

It may be tempting to take a notepad computer and make electronic notes. However, this makes it difficult to establish and maintain a comfortable relationship with the people you are visiting. Taking notes on paper is the way to go.

What to Watch Out For

You need to be alert for anything that can help you design a better product. In particular, take note of the following:

• Environment and facilities. Is it busy? What sort of computers do users have? What level of Internet access? Do they use headsets or standard telephones? Do they have printers, fax machines and photocopiers? Do they have to share these? Do they have to walk to these machines? It's often helpful to sketch a rough map of the work area, so that you don't have to try to remember these details.
• Interruptions. Can people concentrate on their work, or are the frequently interrupted by other applications, people or events? What is the impact of these interruptions on their workflow? Do current systems support these interruptions?
• Applications. What applications, systems and Websites are currently being used? Exactly which screens and fields are used, and in what sequence? Get screen dumps if possible.
• Issues. What problems do users currently have? You should be interested not only in application or system issues, but also workplace issues -- particularly if it is possible to address them in your design.
• Artifacts. Do users have 'cheat sheets' and notes on their computers? Do they have tables or charts or phone lists that they rely on? It may be possible to include some of this information within your application. Get copies of any artifacts, if possible.
• Double-handling. For example, are they entering account numbers in two different systems?
• Workarounds. Are users compensating for poor product design or poor work design by applying workarounds? Will these have an impact on your design or can you accommodate or eliminate them?
• Triggers. What is the event that triggers users to take a particular course of action or begin a particular task? Triggers are often events like phone calls, arrival of emails for faxes, or work queues.
• Hand-over points. When do people receive or hand over tasks?
• Variations. Remember to ask users about whether the work you see is typical and, if not, why not. Ask about what it's like when things get particularly busy (or particularly quiet).

The Day After...

After site visits, you will have an enormous amount of information, and analyzing it can be a challenge.

Contextual analysis has four key outcomes, all of which aid the design and development of the project in various ways. Let's look at each in turn.

Task Analysis

One of the first things to do is to identify the tasks that were carried out. Usually, there will be a relatively small set of tasks, but there may be multiple variations.

For example, imagine you're building a Web application to allow people to book DVDs online. If you spent some time in a video store, you might discover a small set of tasks, such as 'find a movie', 'hire a movie', 'return a movie' and so on. However, 'find a movie' might have several variants: some people would just browse new releases; others might look for a movie by name, or by the name of a director or actor, and so on.

It can be a good idea to draw flowcharts to represent the tasks. The flowcharts should identify triggers (what starts the task?), systems usage, interactions with people or departments, what marks the conclusion of the task, and discontinuities. Although there may be many variations to the flowchart, it can be very useful to have a consolidated view.

A clear, systematic task analysis will help you develop effective information architecture and aid user interface design.

User Needs Analysis

Make a list of the things that users explicitly requested, or that you noticed would have helped them.

Consider whether these needs can be met by your application or Website.

Consider also whether there are proposed elements of a new design that will not be valued by users; perhaps effort can be shifted from them and into the areas that are perceived to be more important.

Through one contextual enquiry, we found that people were reliant on an old application that was expensive to maintain, but they only used it to retrieve one piece of information that was not available anywhere else; by incorporating that information into the new design, it was possible to retire the old application.

Personas

Based on the people you meet on site visits, and on any other demographic or segmentation information available, you may be able to produce personas -- fictitious but representative user profiles -- which can be used as decision aids by design teams.

Reporting

The information you gather during contextual enquiry is often extremely valuable not only to the design team but to other parts of the client organization (for example, marketing).

Take the time to write a report that conveys your findings, or commission a technical writer to write the report.

No Time or Money?

If you really can't get an appropriate level of commitment and resources to carry out a contextual enquiry, consider starting small.

Visit one or two users informally, and take any opportunity you can to visit more. Keep notes, and use these to help make informed design decisions.

Recommended Reading

• Contextual Design: A Customer-Centered Approach to Systems Designs by Hugh Beyer, Karen Holtzblatt (Paperback)
• Observing the User Experience: A Practitioner's Guide to User Research (Morgan Kaufmann Series in Interactive Technologies) by Mike Kuniavsky