In user experience, we often write about and discuss conducting research to understand users and their needs, but have focused much less attention on understanding stakeholders and their needs. This turnaround from a traditional development process—which focused almost entirely on gathering stakeholders’ requirements and gave very little consideration to the needs of users—was once necessary. But perhaps the balance has tipped too far in some cases, with our focus almost exclusively on users’ needs and a lack of adequate consideration or understanding of business needs. Designing an effective user experience requires an understanding of the needs of both the business and users and designing a solution that meets them.
Who Are Stakeholders?
Stakeholder refers to a person who holds a stake, or has a vested interest in a project. Although the users of a product or service obviously have a stake in it, we usually use the term stakeholder to refer to key people in a company that is building a product. This often includes clients, managers, department heads, subject-matter experts—and sometimes, user representatives. For example, for a project team developing a reporting application for a hospital, the stakeholders would include hospital executives, department heads, an IT manager, and doctors and nurses acting as user representatives.
Are User Representatives Users?
When members of a user group come to project meetings to provide their input, we consider them to be user representatives. While including them is definitely valuable, they are different from the actual users we work with in user research—because we talk with them in project meetings, out of the context of their work, and they tell us about their tasks and needs in the abstract environment of a conference room. We can still learn from these stakeholders’ perspectives, but they’re often too close to a project for us to consider their inputs to be user-research data. Many poorly designed products have resulted from simply asking user representatives what they need in the artificial environment of a conference room.
What’s the Difference Between Clients and Stakeholders?
Sometimes people use the terms client and stakeholder interchangeably. Clients are always stakeholders, because they’re the ones who have hired us to work on their project. Thus, they often have the largest stake in the project. Stakeholders also include other people in the client company who have a stake in a project.
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.
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.
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.
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.
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 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.
Principal User Experience Architect at Infragistics
Cranbury, New Jersey, USA
Jim has spent most of the 21st Century researching and designing intuitive and satisfying user experiences. As a UX consultant, he has worked on Web sites, mobile apps, intranets, Web applications, software, and business applications for financial, pharmaceutical, medical, entertainment, retail, technology, and government clients. He has a Masters of Science degree in Human-Computer Interaction from DePaul University. Read More