Perhaps it’s simply the wishful thinking of a James Bond fan (I have all of the movies on DVD), but I find it interesting and useful to compare what I do to other lines of work. For example, last year, I compared user research to ghost hunting.

What can we learn from James Bond?

In both occupations, an expert is brought in to solve a problem. In one case, an evil madman and his deformed henchman are threatening to destroy the Middle East oil fields with a nuclear weapon. In another case, an electronics company wants to redesign its order management software. In both of these critical situations, we investigate the problem by conducting background research, questioning people, and observing behavior. We overcome obstacles to get to the truth and eventually conquer the problem.

Get the Briefing

After an exciting opening action sequence, Bond meets with M, the head of MI6, to learn about his new mission. M gives him the background of the situation, profiles of the people involved, and a direction of where to begin the investigation.

In user research, our M is usually the project manager or the salesperson –the individual who has had the most contact with the client during the sales process. It’s a good idea to have an internal meeting to get all the details and understand the project before the official kickoff meeting with the client. The last thing you want your team to do is go in unprepared and uncoordinated in your first meeting with the client.

Do advance research

Before engaging the enemy, James Bond examines exisiting documents and photographs, gathering background and situational information.

In user research, it’s also important to do advanced research to understand the client and the project. Examine the current interface, background documents, and talk with people familiar with previous research. You can ask the client and stakeholders better questions and you can better understand their answers if you’re well informed before the first meeting.

Don’t rely too much on technology

Bond meets with Q, the technology expert, to get the latest gadgets. And sure, the cool cars and laser watches are fun, but they only give him a slight advantage. Most of his success is due to his own wits, dexterity, and fighting skills.

Likewise, researchers need to be familiar with the latest user research technology (audio and video recorders, cameras, online testing tools, etc.), but the most value comes from people – both those you interact with and you through your skills, knowledge and effort.

Get help from others

We tend to think of James Bond as a loner, but in truth he gets a lot of help from other agents (i.e., CIA agent Felix Leiter) and by allying himself with others (i.e., Pussy Galore, Octopussy, Vesper Lynd, etc.).

User research can be conducted alone, but it’s much easier to have a partner to help you with note taking, handling the equipment, and providing another perspective. In fact, two is the ideal number of people for user research. In addition to helping run the sessions, a second researcher or designer is someone you can collaborate with to understand the findings and discuss solutions. Two heads are often better than one when you’ve both witnessed the same research sessions firsthand.

Get out into the field

James Bond doesn’t sit at a desk in a command center, observing spy satellite images and listening to communication monitoring devices. Even though that’s how a lot of espionage is conducted today, Bond knows that the most useful knowledge comes from being out in the field, talking to people and observing them in person.

Similarly, a lot of user research today is conducted in a usability lab, remotely through web conferencing and screen sharing software, and through unmoderated, web-based tools. But, like espionage, the best information is gained by going out into the field to talk with and observe people doing their usual tasks in their natural context. There’s no better way to understand users and their needs than by seeing their everyday jobs firsthand.

Observe remotely when you can’t get out into the field

In addition to going out into the field, James Bond can use remote surveillance, satellites, and listening devices to gather information.

Unlike spying, we have to get participants’ permission, but we can conduct usability testing and even contextual inquiries through web conferencing and screen sharing software. It may not be as good as being there in person, but it’s better than not being able to do any research or limiting the research to only the people we can travel to.

Spy on people

As a spy, Bond surreptitiously observes suspects. The advantage is that he can see what people naturally do when they don’t know they are being observed.  They don’t act differently; as they would if they knew they were being observed.

Obviously, it’s not ethical for user researchers to spy on people in private locations. We have to get informed consent from participants, which requires us to tell them about the study. The problem is that knowledge of being observed affects behavior. There’s no getting around this dilemma; it’s just something that we have to accept and take into consideration.

Neverthless, we can learn from James Bond in leading discreet observations of people in public places. Unlike spying in private locations, there’s no law or ethical rule against simply observing people in public sites. Remain incognito and observe what people do naturally when they don’t know they are being watched. Take note of the environment, the interactions between people, the artifacts involved, and the problems they encounter.

Interrogate the right people

In addition to observation, James Bond gets much of his information by questioning people –using force if needed.

Obviously, user researchers can never use force (however tempting that may seem sometimes), but interviewing is a key method for gathering information. Start by interviewing your clients and other stakeholders to understand the current situation, the business needs, and the goals for the project. Although observation of natural behavior usually gives you better insights than asking people about what they do, it’s still important to ask questions to clarify your understanding of what you’re seeing.

Report findings to headquarters

Because he’s out in the field and could get captured or killed, Bond periodically updates M at headquarters about the progress of his investigation. Otherwise, they wouldn’t know what was going on with the investigation.

A user researcher is often out in the field conducting research, doing analysis, and creating deliverables. Weeks might pass between reviewing the final research plan with clients and the final presentation of the research findings. Without knowing what’s going on, clients sometimes wonder why research takes so long. Providing periodic updates makes your client and team feel like progress is being made. It also keeps them involved in the research, which makes them feel more invested in the findings.

Avoid capture and escape death

At some point during every mission, Bond gets captured and set up for an elaborate death, whether it’s to be cut in half by a laser, attacked by sharks, eaten by crocodiles, or burned alive by rocket exhaust. After the villain explains his entire plan and conveniently leaves the scene, Bond narrowly escapes.

Although we rarely come across evil villains, we sometimes do get challenged by a particularly difficult client or stakeholder. With these people, it’s important to keep your wits about you to avoid getting injured. At other times, we get captured by long-winded and opinionated participants who completely take over the session, pontificating on irrelevant side-tracks and resisting all of our attempts to regain control of the session. When you find yourself in this dire situation, remain calm and look for a way to wrap up the session. If you can’t reign in a difficult participant, then it’s best to simply end the session.

Defeat the henchmen

Bond villains are always protected and aided in their evil schemes by at least one particularly dangerous henchman. Bond has to fight and defeat the henchman, often several times, before finally confronting and defeating the primary villain.

In user research projects, the villain is the problem that you’re trying to solve (such as a poorly designed application that you’re trying to redesign), and the henchmen are the people and situations that get in the way of solving the problem (such as an IT manager who says the new application has to be created using SharePoint). To solve design problems, you often have to defeat these organizational “henchmen” that cause the problem to exist in the first place. Achieving this coup may require more than interface redesign; it may require changing business processes.

Kill, when necessary

Okay, this one only applies to James Bond. Although it may be tempting at times, unless you’re properly licensed by the British government, please refrain from killing participants or clients.

Sleep with beautiful women

Yeah, sadly, this one too only works for James Bond. There are Bond Girls, but there are no Research Girls (or Guys). It’s better to just keep your mind on the research.

Call in reinforcements

In addition to henchmen, Bond villains often have an army of fighters to defend their hollowed-out-volcano or underwater fortresses. Bond doesn’t attempt to defeat this entire army himself. He calls in British special forces units to fight off the villain’s army, while he focuses on defeating the villain and his main henchmen.

User researchers don’t solve user experience problems alone either. We find problems and recommend solutions, but we need an army of reinforcements (designers, developers, project managers, and clients) to fix the problems. It’s truly a team effort to solve user experience problems. Don’t attempt to go it alone.

Defeat the villain

At the end of the mission, James Bond always defeats the villain, usually surrounded by explosions and massive destruction. But Bond doesn’t always defeat the larger enemy, and some villains (such as SPECTRE leader Ernst Stavro Blofeld) return again in the future.

For a user researcher, “defeating the villain” means recommending solutions to the problems found. Unfortunately, there’s no guarantee that those recommendations will be implemented correctly or at all. If we simply hand over our research findings and walk away at the end of the research phase, it’s likely that the problems will persist. That’s why you should remain involved throughout a project to fight the user experience villains as they continue to resurface.

Conclusion

By this point, you’ve either realized that user research and espionage have more in common than you originally thought, or you think that I’ve made a big stretch comparing the two. Either way, there’s no denying that we gained a different perspective and new insights about the user research profession. If you’re a user researcher, you may never watch a James Bond movie the same way again.

As a user researcher, I’m not proud to admit that there have been times I’ve nodded along and pretended to understand a participant, while actually thinking, “What the heck is this guy talking about?” Of course, it’s a rare occurrence, but when dealing with very complex subject matter, it sometimes takes several research sessions before my “ah-ha” moment happens, and I begin to fully understand what the participants are talking about.

Learning the subject matter is a special challenge for consultants and freelancers who work with a variety of clients in different industries. There’s often very little time to get up to speed on the subject matter. It’s no wonder that clients are often skeptical that someone from the outside can come in and understand their business in such a short time.

Depending on the kind of projects you work on, learning the subject matter can be one of the most difficult aspects of starting a new project. Websites and applications aimed at a general audience are easy to understand and relate to because they don’t require specialized knowledge. For example, a photo site like Snapfish is fairly self-explanatory. That doesn’t mean that you don’t need to do user research, but at least you have enough familiarity to understand and identify with the subject matter.

But what happens when you’re designing an application to track biomedical research data, an electronic medical record, an investment banking application, an energy grid display, or some other complex subject matter? How do you know enough to ask the right questions and understand the answers if you have no prior experience with the subject?

Set the clients’ expectations

At the beginning of a project, clearly set expectations about your knowledge of the subject matter and how much you need to learn to do the project effectively. Don’t be surprised if clients are skeptical that you’ll be able to absorb what’s taken employees months or years to learn.

Admit your ignorance

Clients sometimes expect you to have more knowledge than you do. When the project was sold, you may have been portrayed as, or assumed to be, an expert in the domain. But don’t be afraid to admit your ignorance. Being completely honest about your level of knowledge gives you freedom to ask questions, and it gets people to talk with you about the subject matter at an appropriate level.

Clarify who’s an expert in what

From the beginning of the project, make it clear that you’re an expert in user experience research and design, your clients are experts in the business needs, and the users are experts in their needs. All three groups must work together throughout the project, each using their expertise to best inform the design.

…don’t be afraid to admit your ignorance. Being completely honest about your level of knowledge gives you freedom to ask questions…

Clarify that you will never become a subject-matter expert

Make it clear that you do not need to become an expert in the subject matter. You need to learn enough to plan and understand the research, but you’ll rely on the clients and users to fill in the gaps in your understanding.

Ask stupid questions

Being honest about your level of knowledge allows you to ask questions as needed without worrying if they seem like “stupid” questions. Don’t be afraid that if you ask questions, people will think that you didn’t understand the material the first time around.

Don’t be afraid to be wrong

As you conduct research, you make assumptions, and some of those may be wrong. Make it clear that your findings are a work in progress, you may be wrong occasionally and that you welcome feedback. You are working with the clients and the users to understand and you will revise your findings and recommendations as needed.

Do subject research before user research

Learn as much as you can about the subject matter, the business needs, the users, and their tasks before conducting user research. You need background knowledge to plan the research and to understand what people are talking about and showing you during the sessions. It’s often best to learn about the subject matter in the following small steps to go from a high-level overview to more detailed information. Each step takes you gradually into the subject matter, building on previous knowledge, rather than drowning you in information overload.

Conduct some initial research

Before the project kickoff meeting, it’s helpful to examine online references, client documentation, training and support materials, and to talk with subject matter experts. At first this reference material may be difficult to understand, but it will make more sense and be more useful later in the project. So don’t forget to read it again after you’ve done your stakeholder or user research sessions.

Get a high-level overview at the kickoff meeting

Kickoff meetings usually give a very high-level overview of the project and the subject matter. This is the time to ask general questions about the business, the users, and the system involved in the project. With the large number of people attending and the short time frame, it’s not the time to get too detailed.

Get a demo of the system

Whether it’s a website, application or a physical product, it’s best to become familiar with the system before you conduct the user research. If it’s a website, you can go through it yourself. If it’s a more complex application, it’s better to have someone walk you through a demonstration. Gaining familiarity now will make it easier to understand what you observe later during the research sessions.

Play around with the system yourself

There’s no better way to get to know a system than by trying it out. After a guided demonstration, get access to the system and play around with it.

Conduct stakeholder interviews

Stakeholders are your best source of initial information about the business needs, users, the subject matter, and the system. These are often your clients and other subject matter experts working on the project team.

There’s no better way to get to know a system than by trying it out.

Stakeholder interviews can be conducted as a group working session, but individual interviews are usually more helpful. With a group of stakeholders, there are too many people in the room with the same level of experience and knowledge, making it easy for them to slip back into organizational jargon instead of speaking down to your level of knowledge. In individual interviews, people are more likely to be conscious of your level of understanding and adjust the discussion accordingly.

Individual interviews take longer than one group session, but you benefit from the repetition of multiple interviews. It also gives you time to reassess your understanding after each interview and make changes for the following sessions.

Set the participants’ expectations

Regardless of how much you know about the users and their tasks, conduct yourself as if you’re a beginner. Remind the participants that you’re not familiar with their domain, their tasks, their company structure, or their terminology. Ask them to talk with you as if you were a beginner and take you through their process step by step. Stop them if they get too far above your level or if they revert back to using jargon or unfamiliar concepts.

Gain understanding through the user research

You can learn a lot before the user research, but it isn’t until you begin observing and talking with users that you really understand the subject matter:

Discuss tasks before observing them

Before participants begin performing their tasks, ask them to give you an overview of what they will be doing and how the tasks fit into the larger work process. Having this context up front will help you better understand what you observe during the task.

Learn by repetition

You normally observe several participants from each user group to see patterns in their behavior and hear comments that indicate common characteristics, problems and needs. The repetition of hearing the same information and seeing the same tasks performed by multiple participants is especially helpful for understanding complex subjects. Because it takes a few sessions to develop this understanding, be sure to include enough participants from each user group to learn through repetition.

Record everything and type up your notes

Recordings allow you to review sessions a second time, when you can focus on the information and pick up things you might have missed. During a user research session, your attention is divided between listening and observing, taking notes, thinking of the next question to ask, and maintaining social norms of politely listening to the participant.

The repetition of hearing the same information and seeing the same tasks performed by multiple participants is especially helpful for understanding complex subjects.

Reassess between sessions

It’s helpful to take off a few days in the middle of your research sessions to review what you’ve learned so far and to make any necessary adjustments. Reflect on what you’ve heard, how well the research is going, and whether to make changes to the study, such as additional questions or actions to observe.

Confirm your understanding

Inevitably, additional questions come up after the research is over. You don’t know what you don’t know until you begin analyzing your notes. That’s when you find holes in your knowledge, concepts you don’t understand, and questions you wished you had asked.

Follow up as needed

Ask your clients, the stakeholders and the users follow-up questions to clarify and confirm your understanding. Most people don’t mind, and even appreciate, answering additional questions. If necessary, you can go back to the users and observe certain tasks again.

Partner with an expert

Because technology sometimes limits what’s possible, it’s important to provide realistic recommendations. You don’t always know enough about the technology to determine this on your own. That’s why it’s helpful to have a trusted technology expert review your recommendations to alert you to those that might not be feasible. A technology expert is also helpful to defend your recommendations against those who may incorrectly say that they are not possible.

Get feedback on your findings and recommendations

Remind your clients that you want their feedback on the user research findings and recommendations. Remind them again that the findings and recommendations are not set in stone. There may be errors in your understanding and you welcome their feedback in order to make corrections. This is a team effort and you want their collaboration and input on the findings and recommendations.

Now go out and learn the subject matter.