UX Process starts at Stakeholder Interviews, not User Interviews

My days as a UX consultant gave me the opportunity to work with companies of all shapes and sizes. At some places, I was tasked with establishing a process while at others, I was one of a large team. Although these roles were as diverse as the places that offered them to me, there were some very observable themes common across them.

Problem

I want to talk about one of them specifically — the temptation to jump to user interviews whenever a new feature request comes in from the product owners. This unfortunate beginning then results in the UX team trying to form the problem statement while talking to the users. User interview questions then end up going in 100 different directions and the resulting responses are too broad to come up with anything actionable.

Solution

Begin with stakeholder interviews and take them seriously.

but, I work in a startup and I only have one project manager. I can just get the initial requirements from her in a quick meeting!

False! The stakeholder is not just your boss or your product manager. It is everyone that will be involved in bringing the feature to fruition. This includes — Product managers, Tech managers, Engineers, Customer Success Team, and if the company is small, even the C-Level folks.

Shay, you just said that when you go to an interview with no goals, you end up with really broad un-actionable responses and now you are telling me to jump in head first into stakeholder interviews. What are the goals here?

First, let me congratulate you on your impeccable comprehension skills. You are absolutely right! Coming up with goals for stakeholder interviews though is somewhat straight forward because unlike user interviews, they are usually the same. You need to get an understanding of the following:

• What is the requested feature/product/enhancement?
• What is the expected timeline in stakeholders’ minds? Are they aligned?
• Who are the intended users for the feature/product?
• What are the constraints/worries that exist regarding this effort?

While the broad goals are the same, your questions might be different depending on who you’re talking to. For example, you’ll ask a CTO about technical constraints while a saleswoman might be able to tell you about most frequent complaints from users. If you need help, UserBit lets you manage your stakeholders and provides default questions that you can use as a starting point.

Questions you might want to ask your stakeholders (credit: UserBit)

Synthesis

You have collected all these responses now what? Before you do anything else, you need to make sure that there’s a consensus amongst the stakeholders and your team.

A consensus on what?

Good question! Here are a few things that you should have a common understanding of before proceeding:

• Product or feature definition
• Timeline
• Constraints
• Primary Users
• Success Metrics
• Important Stakeholders

How do you go about summarizing it? If the number of stakeholders is low (2–3) you could just extract your findings manually. If the number is large though, I recommend using affinity diagrams to extract out common themes and conflicting assumptions.

Affinity diagrams are a quick and efficient way of summarizing raw data (credit: UserBit)

Profit!

Make stakeholders part owners of the design process — The most important benefit of this phase is making stakeholders feel like they share ownership of the design process. I can guarantee that very few people have gone to your engineering manager and asked something like “What is your biggest worry about this project?” This kind of interaction not only gives you good data on constraints but also gives your stakeholders a chance to think about the project holistically. Moreover, you get buy-in from these stakeholders who’d more often than not, want to be involved in the design process out of curiosity about what you did with their feedback.

Get everyone on the same page — Stakeholder interviews are vital to getting expectations defined both from project’s perspective and from what UX team delivers. Needless to say, conflicts in assumptions and expectations of stakeholders if allowed to remain buried, result in a lot of issues down the line. We’ve all been there — CEO expects project done tomorrow whereas VP of Engineering thinks 3 weeks, Sales Head thinks this is an exercise to increase adoption whereas product manager thinks UX team will find out what new features the users want.

A better grasp of how to proceed with the UX process — Coming full circle, stakeholder interview and synthesis arm your UX process with the right plan to move forward with. A project that’s expected to be done in 3 months would probably afford a much different process than one that is due in 3 weeks. Similarly, a project whose success is defined by adoption metrics will have much different user interview questions than one where validation is the primary purpose.

In conclusion, Stakeholder Interviews are vital. Don’t skip them however strong the temptation. It doesn’t take that long to talk to a few key stakeholders but the insight gained is very valuable for delivering the best results. If you agree, I’d appreciate a few claps! If you don’t, I’d love to hear from you and how you approach your UX process.