Setting Up Business Stakeholder Interviews Part 2

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.

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.