Setting Up Business Stakeholder Interviews, Part 1

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.

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.