Understanding Stakeholders Through Research

Why Conduct Stakeholder Research?

There are several reasons to begin a project with stakeholder research.

To Gather Information

You need to begin a project with a good understanding of your client’s business, the subject matter, the goals of the project, the requirements, who the users are, and what tasks they perform. Stakeholders are the best people to talk with to gather your initial information.

To Clarify

Sometimes the business requirements may already exist and a requirements document can provide you with a good start, but it’s still important to discuss requirements to clarify their meaning and understand the reasons for certain decisions. For example, if the requirements detail specific features, you’ll want to learn more about the reasons behind feature requests and what they are trying to accomplish.

To Get Consensus

Even if requirements or other project definition documents already exist, you can’t be sure that everyone has read them or agreed on them. So one purpose of stakeholder research is to openly discuss the goals and requirements to ensure that all of the major stakeholders are in agreement on them. This helps prevent basic misunderstandings and disagreements later on that can derail a project.

To Prepare for User Research

Stakeholders are your first resource for gathering initial information about user groups and their tasks, but doing stakeholder research does not obviate the need to conduct user research. Stakeholder research does give you a head start on planning which user groups to include in your research, what tasks and situations to observe, and what topics to discuss. It’s also a good way to get stakeholders involved in and committed to your user research.

Initial Information Gathering

While the scope of your stakeholder research depends on the size of the project, it will typically involve organizing several meetings near the beginning of the project. Here is the process that I usually follow.

Gathering Information Before the Kickoff Meeting

Start by getting a basic understanding of the client and their project before the kickoff meeting. Review the statement of work or design brief and any existing materials from the client. Get an overview of the project by talking with the salesperson, the project manager, or any others who have been involved in booking the project. Find out whether the project allocates resources and time to stakeholder-research activities. Look up the company online to get a sense of what they do. Prepare a list of questions that you want to ask during the kickoff and subsequent meetings.

Getting a Basic Understanding from the Kickoff Meeting

A kickoff meeting normally gives you a basic introduction to and overview of a project. You can ask some initial questions and get a basic demo of any current system. But the meeting isn’t usually long enough to get all of the information you need, and it may not include all of the people with whom you need to talk. However, on smaller projects, this may be your only chance to talk with stakeholders, so you’ll need to take full advantage of the opportunity.

Reviewing Existing Documentation

Ask for and review any information that already exists about the project, product, or users. This could include product documentation, previous user research, analytics, support requests, user feedback, presentations, or other materials.

Getting a Demo and Obtaining Access to the System

For more complex applications, it’s helpful to get a complete walkthrough from someone who’s an expert on the application. Even though you may have gotten a basic demo during the kickoff meeting, you may need a different meeting to go through a complex system in detail. Ask the person doing the walkthrough to go through the application from a user’s perspective, focusing on the most common tasks. It’s a good idea to capture screen recordings of these sessions so you can view them again later on. Get access to the system so you can also walk through the application yourself.

Conducting Stakeholder Research

Individual interviews and group workshops are the two primary methods of gathering information from stakeholders.

Choosing Between Interviews or Workshops

While interviews are typically sessions with individual stakeholders, workshops involve multiple stakeholders in group discussions and activities such as diagramming processes or participatory design. Sometimes it makes sense to do both workshops and individual interviews.

The Advantages of Interviews

Stakeholder interviews can be better than workshops in the following ways:

• You can have a more in-depth and detailed discussion with each person.
• You can hear each person’s true perspective and opinions without others influencing them.
• You’ll hear the views of people who would be quiet or at least less inclined to speak freely in a group.
• Away from their peers, individuals are more likely to speak at your level of knowledge of the subject matter, instead of lapsing into jargon.
• With multiple interview sessions with different people, you’ll learn from repetition, be able to assess what you’ve learned, and have the opportunity to ask additional questions based on what you’ve learned during previous sessions.
• Individual interviews are easier to control than the dynamics of a group session.

The Advantages of Workshops

Workshops also have some possible advantages over individual interviews, as follows:

• When you bring together stakeholders—whether they have similar or different types of roles—the group dynamics can generate better discussions than you would have when talking with people individually. Stakeholders react to each other and bring up questions and issues that would never occur to you.
• Group discussions can both reveal disagreements and help people to reach consensus, both of which are essential to moving forward on a project.
• Because workshops typically take less time than doing many individual interviews, they are a more efficient way to gather information quickly.

Deciding How Many Workshops to Conduct

If you decide to conduct workshops, you should next determine how many workshops to do. The right answer depends on many factors.

Project Schedule and Budget

The time and money available determine the number of workshops that would be practical. On smaller projects, you may have time to conduct only one workshop with everyone who is involved in the project. On larger projects, you may have enough time to conduct multiple workshops.

The Size and Complexity of the Project

On larger, more complicated projects, you’re likely to have too many stakeholders and too much to discuss for a single session that includes everyone to suffice. Since people can allocate only so much time to a workshop and tend to get tired if a workshop goes on too long, it’s better to schedule several shorter sessions.

The Number of Stakeholders to Include

Twelve is about the maximum number of people that you’d want to include in a single session. With more than that, the discussion becomes unmanageable, and some people will get left out of the discussion. So, when there are more than twelve stakeholders, it’s better to break the group into two or more workshops.

Types of Content to Discuss

When there is subject matter that pertains only to certain groups of stakeholders, it makes sense to break those topics into separate workshops. For example, if you were designing a Human Resources application, you might have separate workshops with people in payroll, benefits, and recruiting. This would lead to more relevant discussions and be a better use of the stakeholders’ time.

Relationships Between Stakeholders

You may need separate workshops if relationships between the stakeholders inhibit open conversation. For example, lower-level employees in a workshop with the CEO and other high-level executives might feel too intimidated to express their opinions. So two workshops—one with executives and another with staff—might be more comfortable for them and, thus, much more productive.

Stakeholders’ Locations

Ideally, all of the stakeholders should be in the same room. People on a conference call or video conference tend to get ignored and find it difficult to contribute to the conversation. So, when stakeholders work in different locations, it makes sense either to bring them together in one location or to have a workshop in each location. Alternatively, if none of those options is practical, having everyone join a conference call or videoconference from their own desk can work well—for either a well-facilitated session with fairly numerous participants or for small groups—and ensures that you can hear everyone.

Choosing Who to Include

The next decision is who to include in the workshops. There are three types of people to consider:

• people who make decisions
• people who have information that you need
• people who you must include for political reasons

People Who Make Decisions

You must involve anyone who has the power to define requirements, request design changes, or make changes to the project. You need to get their input and agreement before the project goes forward. The last thing you’d want to do is to leave someone out who could come back later and question decisions and requirements that were set at the beginning of the project.

People Who Have Information That You Need

It may sound obvious that you should include any people who have the information you’re seeking, but that’s not always what happens. Instead of ensuring that you get the people with the best knowledge of the teams and processes that you’re trying to understand, many clients may give you their manager or their manager’s manager. For example, if you were working on a customer-support application, you would want to include call-center support personnel or their manager. But you wouldn’t want to include only the head of customer support, because he or she would probably be at too high a level to truly understand the details of what customer-support personnel experience.

People Who You Must Include for Political Reasons

Sometimes you need to include people simply because of corporate politics. For example, you or your client may need to be able to say that you included people from all divisions or all regions.

Planning the Topics to Discuss

Whether you’re conducting interviews or workshops, you need to figure out what you need to learn, then plan how to get that information. I begin by brainstorming a list of topics and questions to discuss. Then, I organize the list of questions into themes, which I attempt to put in a logical order.

Typical Topics

Every project is different, but there are some typical things that you’ll want to learn at the beginning of any project:

• reason for the project
• history of the project
• goals for the project
• requirements—review and clarification
• user groups and their characteristics
• tasks that users will perform using the product
• environment in which people will use the product
• things that stakeholders would want to learn through the user research

To these topics, you should add more specific questions that will help you to understand your client, the subject matter, and any current product.

Creating an Agenda

Use your organized list of themes, topics, and questions to create agendas for the workshops or interviews. I create two agendas: a high-level agenda for stakeholders and an expanded, more explicit agenda for myself. The stakeholder agenda should comprise a single-page list of the themes and topics that you’re going to discuss, arranged in a logical order. I add subtopics and questions to my own agenda.

Keeping your stakeholder agenda to a single page is important because a multiple-page agenda can seem overwhelming to stakeholders. I keep even my own expanded agenda to a single page, so I can quickly glance down to see what topic we might discuss next. Ideally, workshops should be free-flowing discussions, not strict, question-and-answer sessions. You want to appear to effortlessly direct the discussion rather than constantly look down and page through your agenda to find the next question to ask.

Listing general topics rather than specific questions lets the conversation flow naturally. Stakeholder discussions are unpredictable. Often the questions that you had planned can become irrelevant and different questions arise instead. In an ideal workshop, you would bring up a topic and let the stakeholders discuss it, asking each other questions, and perhaps taking the conversation in a valuable direction that you had never considered.

Planning Activities

The core of stakeholder workshops are discussions, but you can also include group activities such as card sorts, affinity diagramming, participatory design, or game-like activities. The book Gamestorming and the Innovation Games Web site provide some good activities to consider. It’s a good idea to do a pilot test of any major activities before the workshop, to make sure they work well and will fit in the time you’ve allocated for them.

Providing the Agenda Beforehand

When you set up meetings with stakeholders, give them a description of what you’ll be doing, the purpose of the sessions, and the agenda. Seeing the topics that you’ll discuss lets them gather their thoughts, and knowing what to expect helps ease any anxiety or apprehension.

Recording the Audio of a Session

It’s nearly impossible to take detailed notes and effectively facilitate an interview or workshop at the same time. Instead, ask the stakeholders for permission to record audio during the sessions. That frees you up to focus on listening to the discussion and directing the flow. Instead of taking notes on what people are saying, write down additional questions that occur to you and any insights you may have. Review the recordings later to take detailed notes.

Since interviews and workshops mostly involve discussions, audio recordings are better than video, because they provide enough information to understand what you discussed later and are less obtrusive, so less likely to make people uncomfortable. Take photos to capture workshop activities.

Facilitating Workshops

Facilitating a stakeholder workshop is similar to facilitating a focus group. Since others have written extensively about conducting focus groups, I won’t get into much detail here. But some key points to remember are to be flexible and let the conversation flow in whatever direction makes sense, as long as you get the information you need. At times, you may need to direct the conversation back to the topics you need to cover. Ensure that everyone feels able to provide their input. If certain participants are dominating the discussion, you’ll need to ensure that you give quieter or more reticent participants an opportunity to speak.

Deliverables Documenting Stakeholder Research

To save time, there’s often no official deliverable from stakeholder research. Since the primary purpose of these activities is to provide information to the designers on a project, stakeholders often feel that they don’t need a deliverable that reports what they said. This may be fine on smaller projects, but if you’ve talked with a lot of stakeholders during multiple sessions, it’s a good idea to prepare an official deliverable to ensure that all of the stakeholders agree on the requirements and the project’s direction.

A Balancing Act

I hope I’ve convinced you that understanding stakeholders is just as important as understanding users. Stakeholder research is the first step toward understanding what we need to design. Our design solutions must address both business and user needs. Just as we cannot balance business and user needs without understanding users, nor can we balance them without understanding the needs of business stakeholders.