Setting Up Business Stakeholder Interviews Part 2

Written by: Michael Beavers

In part one, Michael shared his first four lessons learned on navigating company politics to set up and prepare for great stakeholder interviews. Here, in part two, he covers his last five tips.

Relatively few people have a complete A to Z view of who touches the user in sequence. If you are conducting stakeholder interviews and forming a strategy, this responsibility may fall to you.

5) Determine how each stakeholder influences the User Experience

While strategies for new sites, features, content, and tools should bubble up from interview findings, outside research, server log analytics, and other information, you will probably begin work with a fairly clear sense of the problem space.

Start by guiding your client toward a clear set of issues to attack. Are users dropping off at a key point in a commerce interface? Are users not interacting with a business-critical application? Is your client simply trying to build an innovative feature that will set them apart?

Whatever the problem, you can often identify key breaking points: where do your stakeholders have deliverables that contribute to or influence the user experience? This can include people who review work at different stages, create content, measure user response, or hit the “publish” button on a web page content management system.

Remember the earlier example where that large company was spamming its own customers? Rather than simply interviewing only the person in charge of hitting “send” from the email marketing engine, I tried to consider all of the touchpoints that staff members may have on the user experience—and then I interviewed as many of them as possible to gain a sense of their process.

Stakeholders plotted along user experience
Try plotting your stakeholders along what the user experiences to get a sense of how interactive products are built and maintained in an organization.

Given any email campaign, there may be a large number of stakeholders who create the content, build it into the email and landing pages, try to anticipate the tools that users will wish to interact with, provide a means to navigate there, and then measure the results. Imagine all the brand managers, content managers, designers, product managers, developers, CRM analysts, and IT professionals involved in this process or reviewing the success of a series of email campaigns over the course of a year—it really can take a lot of people to get the work done, especially in a large company.

Relatively few people have a complete A to Z view of who touches the user in sequence. If you are conducting stakeholder interviews and forming a strategy, this responsibility may fall to you.

6) Guide your client on introducing you to stakeholders

You may be approaching your stakeholders as an internal or an external resource. I typically arrive at these engagements as an outside consultant, but the way you are introduced to your stakeholders as an inside resource could be essentially the same.

When you or your client are setting up interviews, it is best to clearly state the purpose behind the request—which is more often as not tied to the problem space. Set a context appropriate to major site or feature enhancements. A large part of this is gathering business requirements, understanding where bottlenecks exist, and how the user experience may be improved. Stakeholders will want to be a part of this, but many will not have been through the process or understand how the information they provide to you will be used in the site design.

Earlier, I described how many stakeholders will see the interview as an opportunity to vent their frustrations. This can be very healthy for the overall strategy. On several occasions, I’ve had to assure anonymous attribution to certain stakeholder comments. This protection may provide you with more candid input. When drafting a strategy report or a design document, it is fine to simply cite a contribution to a “department stakeholder” and assure your interviewee that this is how you will address attribution. This goes without saying, but you must actually make good on that promise to maintain your stakeholders’ trust.

Here is a loose script for your client to introduce you, or for you to introduce yourself, to stakeholders:

  • “We are building our next generation (Web site/application/User Interface for…) and need to understand how you rely on the Web to achieve your goals. This plays a key part in helping us form the business requirements for the project”.
  • “X is here to learn you’re your insights and perspective which will prevent us from designing our next Web site arbitrarily.”
  • “The first step toward building a new site/application/UI is to gather business requirements. We’ve identified you as a key stakeholder who can provide some of these.”
  • Your comments and insights may be included in strategy write-ups and design documents, but, as we’ve already mentioned, we can make sure they are attributed anonymously if that is your wish.

7) Understand that no stakeholder intentionally subverts user experience

As a proponent of User Centered Design, I am often surprised by the way larger organizations make content, navigation, and functionality decisions. While more companies are establishing better processes and hiring UE professionals, many are still figuring out who to hire and how to manage workflow after about a decade of building more company-centric architectures.

As an interviewer I have to remind myself that while I ultimately design for site users, stakeholders’ business motivations for content and functionality may be driven by ingrained adherence to processes that do not include thinking about users. While this often results in a poor user experience, we have to remember that our stakeholders’ motivations for enhancing and maintaining websites are generally well-intended: everyone wants to develop the best possible product, but how this is achieved is constantly evolving.

It is important to help educate them that tactics that contribute to short-term departmental goals do not always align with the best interests of broader strategic goals for the company or with user tasks and intent. I like to keep a couple of statements at the ready, if I think the interview is going astray and needs some alignment toward creating a better user experience:

It is important to balance fact-finding efforts with a warm empathy that builds relationships with stakeholders and teases out the information you need to do your work.

“What you say is true and makes perfect sense. Good sites are a balance between achieving departmental or business metrics with user needs—and we strive to hit that as perfectly as we can.”

“Hmmm…perhaps your idea is worth exploring. Depending on the prototyping budget and overall research timeframe, we can test that concept with users and see if they like it. We should build for common ground with our customers, don’t you think?”

When we have good client relationships, it is easy to form intellectual—and even emotional—alliances with whoever has commissioned our work. However, it is important to be aware of how these client biases influence how you run your stakeholder interviews. Conduct your interviews much as you might if you were running ethnographic research with users: guide the discussions with regard to your research objectives, but do not aggressively steer them to suit a case for UED. It is important to balance fact-finding efforts with a warm empathy that builds relationships with stakeholders and teases out the information you need to do your work.

If you pull this balance off and engage stakeholders collaboratively, you will find them to be very forthcoming with information and even recommend other stakeholders or documents you may find useful.

8) To structure or not to structure? Or to semistructure?

A client once asked if I could build a semi-structured, uniform discussion guide for stakeholders, log their comments, and then process the logged comments as our user research team had done during preliminary persona work. After thinking about it, I realized there was really no good way to build a discussion guide that was uniform enough for the various levels and roles of our research population without placing unnecessary constraints on the types of information we needed for the strategy.

While user research relies on recruiting increasingly similar kinds of users and categorizing the data to form distinct personas, stakeholders are impossible to uniformly categorize, even from one company to the next. IT managers, marketing directors, and customer insights researchers at one company have vastly different skill sets and professional responsibilities from the next. Uniformity is therefore best achieved by the way you deliver your questions and the collaborative and familiar mood you establish at the beginning of each interview. Most interviews benefit from a little structure, but too much structure stifles the organic evolution of the conversation.

On more than one occasion, I’ve listened to a stakeholder speak about their day with little apparent relevance to the information I was trying to gather—only to hear them land on topics germane to the user experience. In fact, one of my favorite questions is to ask stakeholders what a typical day in their work life is like. What seems like an icebreaker actually yields important insights into their frustrations or what they would like to see happen with the site.

Sometimes if you let people vent a bit about how hard it is to get their stuff online, they will often also reveal nuggets that feed a really good content or navigation idea. Applying too much structure in your interview can bury important symptomology.

9) After the interviews are over, keep your stakeholders in the loop.

One of my clients once commissioned an interactive strategy that eventually expanded to include personas developed through user interviews. This added several weeks to the total study time, and I assumed my client would let all of the stakeholders know that the final findings report would be delayed by about a month. She didn’t.

This was not my client’s fault, however. Because I took the time to establish a personal rapport with my stakeholders, I should have done a better job of informing them on the progress of the study which they played such a central role in creating. Instead, they were asking my client where the strategy was for which they provided input was late.

The lesson? If you swap business cards and get to know your interview subjects by name, it really takes little additional effort to email your “stakeholder design team” (which is what they are) periodic updates on the progress of your work. You will also often find that follow-up interviews are appropriate, appreciated, and yield helpful clarification on earlier points. If after the interviews your stakeholders call with new ideas and email supporting documents or articles they come across, you’ve built a great relationship that could make your design even better.

If you take time to thank them for their time and their valuable insights, they will also feel more invested in the process and be more likely to take a more active role with ongoing site enhancements, content updates, and new user experiences.

Lastly, if you are conducting user research in a lab setting, I highly recommend inviting your stakeholders to sit “behind the glass” with you. There is nothing like seeing a real customer or user giving their honest impressions or demonstrating how they interact with a product to drive home the value of user research and testing.

Conclusion

One of the great things about interviewing stakeholders is that there are few better ways to learn about a company, how things get done, and the multitude of personalities behind website operations. When combined with internal company research, reports on the marketplace from industry analysts, Web analytics, and user research, stakeholder interviews are a cornerstone for thorough interactive strategies.

The only way to develop a good technique for these interviews is to dive in and perform them. While interviewing does not require special training, a certain amount of thoughtfulness in how you recruit stakeholders, protect the integrity of your work from company politics, and integrate the findings into your design recommendations will pay off in far superior user experience.

Setting Up Business Stakeholder Interviews, Part 1

Written by: Michael Beavers
Interviewing is both art and science, and it is something that any UE practitioner with a little additional time and moderation skills can employ to extract clear business requirements.

For those who build websites and applications for a living, it is important to understand the realities of how clients work in order to guide effective strategy, IA, and user research aligned with business goals. Interviewing different people who deal with a company’s website will help you simplify complex strategic directions, create appropriate research plans, develop information architecture, and design interactions for great user experiences.

Interviewing is both art and science, and it is something that any UE practitioner with a little additional time and moderation skills can employ to extract clear business requirements. Without this foundation, business requirements can be unclear and deadlines for launching new sites, features, and content can be unrealistic. Worse, companies may launch features that users do not really want. Early and effectively gathered stakeholder input is also valuable for determining directions for user research during new site and product design.

It’s not necessary to be an MBA-level strategist or have a background in user research to be an effective business stakeholder interviewer. Those with these backgrounds will find their research skills can come in handy, but some of the best stakeholder questions I’ve witnessed have been posed by visual designers and developers.

It is also important to understand how company politics can negatively impact your work. Your clients are only human, and they are as subject to company turf wars and coworker fatigue as anyone: “Oh, I guess you’ll have to speak with Bob, too…he heads up such-and-such, but he doesn’t know what he’s doing”. As an interviewer, you may find that Bob may know exactly what he’s doing and have some really great ideas. How you manage company politics can contribute to achieving—or completely unraveling—a good user experience.

For some interesting background on conducting and analyzing stakeholder interviews, I suggest reading Jonathan Boutelle’s B&A article on Understanding Organizational Stakeholders for Design Success. He also provides an excellent list of additional reading resources at the end.

While I touch on many of the best practices Boutelle mentions, the following suggestions pay special attention to the influence of company politics on stakeholder interviews and how you can avoid some of the biggest pitfalls by properly recruiting subjects and setting up your interviews in a way that minimizes the effects of client bias.

1) Understand your problem space

While this sounds terribly obvious, it is always a good idea to begin with a design or business challenge that you plan to address head-on. Defining this goal will also help you determine who is important to interview, and how to set up your discussion guides and formulate your questions.

Are you creating a whole new website? Are you focused on improving a specific tool? Are you reevaluating site content with regard to user needs?

Because the web is of central importance to so many companies, you almost certainly will have plenty of people interested in providing input. Understanding the problem space will help you prioritize relevant stakeholders and eliminate unnecessary ones.

Even within well-defined stakeholder groups, it is easy to get sidetracked on tangential information and issues that do not really contribute to your research goal. At the same time, recognize that you will not always be able to control the topics or the quality of the information. Your data can only be as good as the people you are interviewing. If they have an agenda or an axe to grind, let them run with it and see where it takes you—especially if you can bring the conversation back to the product or strategy you were hired to create.

The insights from these interviews have everything to do with what you are ultimately going to build. Regardless of whether you will deliver strategic findings, a roadmap that outlines research direction, or even information architecture and initial prototypes, consider the reason you’re speaking with these people in the first place, and design your discussions accordingly.

2) Be prepared for the unexpected

Your interview experiences may vary from confrontational to deeply and satisfyingly collaborative. As an interviewer, you stand a good chance of being asked to help build alignment to a strategic vision or manage organizational expectations. As a UE practitioner, you may also wish to help various stakeholders within the company maintain focus on what is best for their customers and users.

However, because large sites, applications, integration projects, and their budgets are driven primarily by business need, stakeholders frequently have their performance measured against business goals, rather than users achieving their goals. If you are a User Experience professional, this will seem backwards, but it is the reality for how many corporate site owners work.

Here’s a story that illustrates this:

At a large, global organization, we discovered that some unfortunate customers were receiving slightly different versions of the same email up to 24 times each month. We never expected that a company would spam their own customers, but that’s not the surprise.

When we reported the issue to our client, the brand and product managers sending redundant emails were not immediately willing to scale back or coordinate email campaigns because each was being evaluated on successful monthly distributions and some baseline click-through metrics.

This unexpected issue naturally made its way into our strategy document and company management implemented sweeping changes to CRM profiles, governance of marketing databases, and how departmental performance would be measured. Without these changes, no amount of user interface changes would have aided the overall user experience. Had we assumed that a global company would never spam their customers, this issue would not have been revealed.

3) Identify and recruit stakeholders at multiple levels and departments

Stakeholders can range from management leadership from various departments to on-the-ground employees. Who is ultimately regarded as a stakeholder by your immediate client can be guided by relative influence within the organization, how often they leverage interactive media to achieve their goals, and those who are directly or indirectly causing site updates to occur most frequently.

While we should tell clients who we’re interested in speaking to, it is good to remember stakeholders can come from anywhere in the organization—often from unexpected places.

During the recruitment stage, let clients guide you toward stakeholders who leverage, benefit, or work closely with the company’s interactive managers. The list of stakeholders should also include those who have a part in website builds and maintenance, or actively manage or plan large-scale systems integrations. You may find that your initial stakeholders may recommend others you should interview, but it never hurts to ask if there’s someone else you should be speaking with.

A few potential stakeholders to interview:

  • Managers with direct oversight of the public website
  • Team members who produce and manage content
  • Email content and distribution teams
  • Media planners
  • IT managers who oversee back-end systems
  • CRM managers
  • Customer insights and research teams
  • User experience leads
  • Team members in charge of creating or brainstorming new tools and features
  • Outside consultants and agencies

While we should tell clients who we’re interested in speaking to, it is good to remember stakeholders can come from anywhere in the organization—often from unexpected places. While our long-term goal is to create a user experience framework, we have to remember that along the way we may also be creating or influencing interdepartmental operations within companies.

Because you may be interviewing a representative sampling from across an enterprise, you may wish to consider philosophically where you stand as a consultant or user experience professional: are you constructing a reflection of the current organization for user benefit, or do you view your role as more of an organizational change agent? For an interesting viewpoint on this topic, I suggest reading Tom Reamy’s article: Enterprise Information Architecture: A Semantic and Organizational Foundation.

The most important stakeholder interviews you will conduct are the early informal discussions you have with your immediate client. As you talk about whom to schedule as stakeholders, try to extract details that give you a sense of what each stakeholder does on a day-to-day basis. Are they typically focused on getting a campaign or content upload done next week, or are they in the middle of a multi-year CRM implementation? Do they deal in tactical execution, or are they tasked with more strategic initiatives? Gaining some insights into how your immediate client views their website will give you a better sense of how aggressively you will need to recruit an appropriate mix of stakeholders.

4) When identifying influential stakeholders, skip the org chart.

When time or budget requires prioritizing my stakeholders, I usually like to try to figure out what kind of weight various people pull within the organization. Interestingly, org charts and job titles are not always accurate representations of stakeholder influence. Understanding stakeholders at this level helps you better prepare for each interview, determine the order in which to schedule them, and get an early and accurate sense of the political landscape your immediate client may be dealing with.

It will also help you understand the gaps between what is right and what is actually achievable when it is time to implement your designs. Be aware, however, that knowing a stakeholder’s influence is another opportunity to allow client bias to creep in to your line of questions. If a stakeholder does not perceptively wield a lot of power, it doesn’t mean their ideas are not important.

This is why it is important to not limit your interviews to the most senior-level people. I find it helpful to also recruit influential lower-level employees. Be open to pleasant surprises and insights and prepare your client accordingly. Often, the front-line professionals who do the work—instead of manage it— have their fingers on the pulse of what is really happening.

In the real world, seniority and status are not a true reflection of who wields influence in a community; knowledge and insight comes from just about anywhere. Within the construct of the company, gauge who has the most influence:

  • Which of your stakeholders interacts with the most departments?
  • Who serves as a touch point with the most people of varying levels of seniority?
  • Who do coworkers admire and listen to?

Pay attention to what they all have to say.

stakeholder influence chart

The above chart shows an alternative way to plot the influence your stakeholders may have. (Every company is different, of course.) While starting with more senior stakeholders is fine for getting a sense of who is responsible for what, org charts often do a poor job of depicting who actually does the work and really knows what is going on.

Consider your body of stakeholders against the problem space for your project. A short-term, tactical interaction problem may require a very different set of stakeholders from a long-term strategic one. If you can match up your stakeholder recruit to the problem at hand, you can eliminate unnecessary interviews and maximize the ones that really matter.

In part two, Michael Beavers covers his last five tips for conducting productive interviews with stakeholders.