Contextual Enquiry

Contextual Enquiry (CE) is a technique for examining and understanding users and their workplace, tasks, issues and preferences.

CE can be used to produce user needs analyses and task analyses.

The results of a CE feed directly into the design process.

Although CE is time-consuming, it uncovers a wealth of invaluable data.

When is CE appropriate?

CE is appropriate whenever you need to develop or communicate an understanding of the users of an existing or proposed system.

How is a CE conducted?

A contextual enquiry consists of visiting several users on site, observing them carrying out their tasks, and analyzing and documenting the resultant data.

How many people are needed?

Two people should be involved in any site visits, if possible. It is not possible to capture all the available information, but using two people maximizes the data returned.

At least two people should be involved in analyzing the data.

Site visit materials

When carrying out site visits, you will need the following materials:

• A list of representative users. Include both expert and novice users in your visits.
• Logging sheets. Expect to make copious notes. You may consider audio- or video-recording; however the unpredictable nature of the activity often makes this difficult.
• Demographic questionnaire for user profiling.
• User satisfaction questionnaire.

How do you analyze the data?

• Immediately after each site visit you should enter your data into a word processing program. Your notes should be at the lowest possible level of granularity.
• Number each note, and print them out on labels or cards. Use a system that allows you to trace every individual note to its source (for example, ‘User 1, Note 57′).
• Use the notes in sequence to construct sequence models of the tasks carried out.Use affinity diagramming to group all related issues.

Site Visit guidelines

Remember that the purpose of site visits is to learn from your users.

• Ensure you obtain appropriate approvals from management and employee organizations.
• Try to minimize disruption. However, try not to accept a time-slot that will not enable you to see the work being done in a typical fashion.
• Avoid preconceptions about the users and their tasks.
• Ensure that you do not give negative signals to the users, either verbally or by your body language.
• Do not prompt users to carry out tasks differently, or in an order other than the one they use normally.
• Do not rely on users’ recollection of how they carry out tasks. Instead, ask them to carry out the actual tasks while you are on site.
• Listen and watch attentively. Remember that the users are the only domain experts.
• Be respectful of your users, their employers and colleagues.
• Be flexible. It is common to arrive on site to find that users’ expectations do not match your plan, no matter how much effort you may have put into communicating your requirements. Be prepared to make the most of available resources.

Guidelines for data analysis

• Avoid unsupported conclusions. If a conclusion appears to be correct but unsupported, re-examine the data and your method to see whether you have missed anything.
• As a rule of thumb, plan for four hours of analysis time for every one hour on site.
• Be prepared to contact users by phone to verify any observations which are doubtful.

Requirements Gathering

Three Types of Requirements Gathering

There are many different activities that are a form of requirements gathering. So many that it can be difficult to determine which approach to use in what circumstance. By classifying requirements gathering into three different types of activities we can simplify the choices.

The nature of a requirements gathering task should affect the mindset with which you approach it. Some tasks are “do it like this” tasks, while others are “you’re the expert – tell me what I need” tasks. Very different approaches to solving problems. We’ve presented ten requirements gathering techniques in the past. In this article, we categorize the situations in which many of them are more effective than others.

There is an over-arching or over-riding goal of only doing extremely valuable work. That will frame your choices about what requirements to gather. Any given product or project may have one or all of the following.

Gathering Existing System Business Requirements

In a migration project, the goal is to improve the way a company is doing something they are already doing.

There is a continuum that defines the boundaries within which the new system will be deployed. Essentially a massive design constraint in the form of explicit charter and often implicit budget limitations. The location of a given project on the continuum will determine how many of the requirements for the new system are expressed as “do it like the old system.”

The requirements gathering techniques that are most effective in this environment are the ones that help you identify the existing system’s behavior and requirements. Has anyone ever worked on a project where someone said “Here are the requirements we used to build the old system. Use these.” [A few hands pop up.] In how many of those projects did the requirements match the existing system? [Hands go down. Groans and chuckles and mumbles wash across the blogosphere.] And for the three people with thier hands still up – “And were those requirements still relevant?” [Roaring applause from completely swayed audience, followed by many links from other bloggers.]

In the real world, you have to validate, rework, and define for the first time the requirements that describe the existing system. Here are techniques that work best in this situation.

• Document Analysis. Those old requirements documents will have good information, as well as bad. Analyze the docs to find the gems. Also review training procedures, OOA/OOD diagrams, online forums, or call-center knowledgebases.
• Interview Subject Matter Experts. Interview the people who truly understand how the existing system works. These could be experts on the implementation (the developers who wrote it), people responsible for compliance or policy adherance, or simply the lady who remembers everything (correctly).
• Reverse Engineer Existing System. Document analysis may not get you completely there – you may have to [shudder] review the source code to figure out what is actually happening.
• Existing System Interface Analysis. An analysis of the user interface is the black-box equivalent of reverse-engineering the source code. The system has an event-response model of some sort. Map out the behaviors that the system exhibits in response to inputs and events.
• Observation. Ethnographic research is the study of users as they use an existing system. Watch how people do the work today. In addition to understanding the application better, it will present you with insights about the frequency of use of particular functionality.

This type of requirements gathering can be both difficult and thankless. Project sponsors have been known to say “make it like that.” and expect that that would be sufficient requirements definition. People (who haven’t gathered requirements) assume that if there’s a working version already in place, then defining the requirements to recreate it will be simple. It isn’t. There are often implicit requirements that are not obvious from reverse engineering an application.

Business analysts will run into this type of requirements gathering when displacing legacy applications. Product managers will additionally run into this form of requirements gathering when performing competitive assessments.

Gathering Known New Business Requirements

When a project has been funded, or a decision to create a new product has been made, there are already some well defined goals if not lower level requirements. Responding to an RFP (request for proposal) provides the first opportunity to gauge these “known” requirements. Usually the language of the RFP will tip the hand of the client, revealing their preconceptions and expectations.

The requirements gathering techniques that differentiate themselves for this type of requirement gathering are the ones that focus on communication. SME interviews help you reverse engineer an existing system and understand operating constraints. Interviews with other interested parties at a “step up” in perspective are the key here.

• Stakeholder Interviews. There are many stakeholders for a given project. In addition to the users, there are the people who’s objectives depend upon the user’s activities. Interviews with stakeholders will define these ultimate objectives, and present the context for making prioritization decisions. Active listening is one of the most effective ways to make your interviews valuable.
• JAD Sessions. JAD Sessions are great at bringing ideas to the table and vetting them amongst interested parties, who all contribute in a structured meeting format.

Gathering Unknown Business Requirements

Exploration of the unknown can be the most exciting part of product management and business analysis. The most concise difference I’ve come up with between the two is that product managers focus on extrapolating value and opportunity across customers to define a market, where business analysts are focused on the needs of a single customer.

• Brainstorming. Brainstorming removes the barriers of conventional thinking and can uncover great ideas, and really bad ideas that inspire great ideas. Brainstorming promotes lateral thinking that uncovers ideas that may be missed otherwise.
• Idea Seeding. Idea seeding introduces constraints into a “brainstorming-like” activity to make it even more effective.
• Prototyping. A physical (or visual) model often inspires people to great ideas. It also is very effective at validating your great ideas after you’ve had them.

Hat Tip

Thanks David for your article on the three types of requirements – concious, unconcious, and undreamt. It inspired us to flip the easel and write on the other side of the paper.

Summary

Every requirement gathering technique can be applied to any type of requirements gathering activity. Some techniques will be markedly more effective than others. The makeup of your team will affect the overall effectiveness of each technique. Our experience has been that these approaches are most apt, given roughly equivalent effectiveness with each technique.

They simply make the job easier.

User experience design

User experience design takes a holistic, multidisciplinary approach to the design of user interfaces for digital products. It integrates interaction design, industrial design, information architecture, visual interface design, instructional design, and user-centered design, ensuring coherence and consistency across all of these design dimensions. User experience design defines a product’s form, behavior, and content.

Usability

The characteristic of being easy to use, usually applied to software, but relevant to almost any human artifact. What makes an artifact easy to use? Broadly, something is easy to use to the extent that it effectively performs the task for which it is being used. Ease of use can be measured by how quickly a task is performed, how many mistakes are made, how quickly the system is learned and how satisfied people are who perform the task. Usability may also include factors such as safety, usefulness, and cost-effectiveness.

How is interaction design different?

It’s easy to understand the confusion, since interaction design as a discipline borrows theory and technique from traditional design, psychology, and technical disciplines. It is a synthesis, however—more than a sum of its parts, with its own unique methods and practices. It is also very much a design discipline, with a different approach than that of scientific and engineering disciplines. In an effort to clarify this, I offer the following definitions for interaction design.

Interaction Design is a design discipline dedicated to:

• Defining the behavior of artifacts, environments, and systems (i.e., products)

…and therefore concerned with:

• Defining the form of products as they relate to their behavior and use
• Anticipating how the use of products will mediate human relationships and affect human understanding
• Exploring the dialogue between products, people, and contexts (physical, cultural, historical)

Interaction design is also a perspective that approaches the design of products in several different ways:

• From an understanding of how and why people desire to use them
• As an advocate for the users and their goals
• As gestalts, not simply as sets of features and attributes
• By looking to the future-seeing things as they might be, not necessarily as they currently are

Given these definitions, interaction designers must:

• Learn new domains quickly
• Solve problems both analytically and creatively
• Be able to visualize and simplify complex systems
• Empathize with users, their needs, and their aspirations
• Understand the strengths and limitations of both humans and technology
• Share a passion for making the world a better place through ethical, purposeful, pragmatic, and elegant design solutions

Many academic institutions with new or established interaction design and HCI programs are beginning to develop an understanding of interaction design and the qualities and skills required of interaction designers.

Other paths

But, do you really need a Master’s Degree or Ph.D. to practice interaction design? There are advantages to rigorous studio training combined with adequate breadth courses (in art, business, humanities, and science), to be sure. But some things, as in any discipline, can’t easily be taught. Empathy with users and the ability to conceptualize working solutions (and then refine them ruthlessly) are difficult skills to teach. At Cooper, we look for people with these talents, regardless of their formal education. Some come from traditional design backgrounds (industrial design and graphic design), but most have an eclectic education in the humanities, technology, or both. Many have had significant experience in software development organizations, working as technical writers, project managers, customer or technical support staff, and even programmers, where they created interaction designs out of pure concern for users being ill-served by technology.

If you are considering interaction design as a possible career shift, here are a few things to keep in mind:

• Designers seldom code—if you are attached to programming, all power to you: the world needs more design-sensitive programmers. But unless you have complete control over your projects, you will be short-changing your users by trying to design and develop at the same time—it’s a conflict of interest. So, if you can’t stomach the thought of abandoning programming, interaction design may not be for you.

• Usability research is tremendously important, but it isn’t design. It identifies problems, but doesn’t (except at the most detailed level) suggest solutions. Can you envision and refine broad and detailed solutions, or are you more comfortable extracting facts from known situations? If the latter, then usability may be a better focus for your interests.

• Temperament is important. The best interaction designers I know are interested in everything, and willing (even eager) to immerse themselves in unfamiliar territories to learn and absorb. They are also very concerned about people as individuals and the human condition in general.

• Designers all need some basic skills; interaction designers should be able to draw or write well (doing both is rare and valued), and must be able to communicate excellently with both their colleagues and their clients. The toughest skill to acquire is that combination of creative insight and analytical thinking that is the hallmark of a great interaction designer.

If any of this resonates with you, you may be an interaction designer in the making. Good luck in your pursuits!