The Stakeholder Interview - Vincent Klijn UX

The Stakeholder Interview to Understand the Business

User Centered Design is all the rage these days. UX Designers are “the voice of the customer.” Whether this is true at all, is a completely different discussion, but I feel that we, as a design community, at least should be crystal clear what we mean when we say something like this.

As UX Designers we are the voice of OUR customers!

These are the employers and corporations who hire us to help achieve certain organizational goals. This means every project should begin with understanding what the product or service is supposed to accomplish:

Is it primarily meant to build brand identity?
Is it primarily meant to reduce operational costs?
Is it primarily meant to generate more revenue?
Why is the project important to this company?
What is the reason for the chosen release timeline?
How ambitious are we allowed to be with our design?

So, before we start thinking about prototypes and user testing, we have another very important job to do; interviewing stakeholders. Stakeholders are, after all, the people who fund, build, test, market, sell, and support our future products or services.

A Little Preparation

Your first task is to identify all stakeholders who might be of influence to the project. This can be a difficult job right away. A small startup probably only has two or three stakeholders, but a large corporation could have as many as 50 stakeholders for a high visibility product.

There are a few pointers to keep in mind when scheduling interviews:

Try to speak to each stakeholder individually.
If you must, limit attendance to a single group of stakeholders. One of your goals is to get to know the lay of the land – who is frustrated with whom and why? What is the range of different viewpoints among different stakeholder roles? Etc.
Conduct stakeholder interviews in person.
Another goal is to establish good relations with these decision-makers and that is easier done face-to-face. It also gives you a chance to build credibility and goodwill, which could come in handy later.
Whenever possible, bring other members of the design team.
The things that will be said are probably important for the project, so hearing them first hand can be beneficial for the team later. Of course you will need to strike a balance with not overwhelming your stakeholders with a hearing committee. Make sure one person leads the interview and the others only make notes.
Prepare the interview well.
This sounds obvious, but one thing that is often forgotten is providing the questions a few days before the interview. That way the stakeholder has time to prepare the answers and you will gather better information and less “I will come back to you on that.” Try to get the maximum result without wasting precious time.
Be aware of the hidden executives.
Once I had a stakeholder who mentioned a certain Richard more than 5 times during the first half hour of our session. Naturally I had to talk to this mysterious Richard myself, as it became obvious he had major influence.
Dig in for the problem, not the solution.
Everyone has ideas and opinions, certainly when it comes to design. Listen to them, looking for value, but make sure to dig deeper and find out what problem we are trying to solve.

Questions to Ask

This depends on the stakeholder’s role within the project of course, so I will split this up in several sections. The list below is not exclusive, exhaustive, nor in chronological order; it serves as a starting point, a framework if you wish.

You want to keep the interview as conversational as possible, rather than turning it into a question-answer session. It is fine though to bring a list of topics you want to cover and keep track of things that way.

One final piece of general advice: never assume you already know the answer. That one will come back and bite you! Ask anyway!

General introduction to get things going

What’s your role when it comes to this product?
Start with something easy like this. Answers might surprise you and give unexpected insight or additional information.
What was your previous role?
Gives insight in experience; maybe in another field that might be useful later.
What, in your opinion, is this product or service all about?
Let’s see which aspects of the product each stakeholder finds the most important. Sometimes this leads to a blur of buzzwords; make sure to follow up with more questions to get valuable information.
What, in your opinion, is this product or service NOT about?
Just as important. This will give you an idea of the boundaries that exist and what needs to be accomplished to reach those boundaries. It will also provide insight in how realistic each stakeholder is about the goals that exist.
Who is this product or service for?
When talking to non-marketing people pay extra attention to this question. The assumptions may vary widely and if so, consensus must be reached along the way. Otherwise releases will always be meet by objections of those who still differ in opinion about the target audience.
When is the deadline?
Even with iterative production processes people will have ideas about when the product must be “finished”. If these are spread wide apart between different stakeholders, it might be time to inform the product owner. Be aware that marketeers usually are optimistic, while engineers tend to be pessimistic when it comes to releases. It’s their nature.
Do you have any worries about this project? What is your worst case scenario?
Before you ask this question, make sure you have established trust and everyone is at ease. It might be smart to save this for last.
What, in your opinion, should this project accomplish for the company?
This actually is an important topic. It might surprise you how many stakeholders will have no idea, or the wrong idea (compared to for example the higher senior officers) about the business’s goals. If this is so, make sure you and your team advocate the true goals throughout the whole process.
When, in your opinion, will this project be a success?
This is a great question to ask. As a Senior Designer I am always looking to turn stakeholders into sponsors; executives who are actively supporting the design team. Knowing what they are looking for as an end result can be of great value.
Is there anyone we should talk to that we have missed?
Check with the product owner if any names mentioned can be of true value. Not only keeps it your PO in the loop, he or she can also judge whether this is worth the time investment.
How would you like to be involved during the remainder of the project and how can we best reach you?
Sound obvious maybe, but this is an important final question to ask. Make sure senior decision makers remain involved at key moments.

Senior Executives

Projects benefit from having at least one top level executive participating. These usually have cross-functional authority and if you succeed in turning him or her into a sponsor of the project, getting them really on-board, that would be great.

Busy schedules and usually other priorities than your project, can make these difficult. Keep the questions limited to the ones above, and add just a few specific extra:

What do we need to know that you feel other have not mentioned yet?
Seniors should have a high perspective strategic view, which can add valuable insights about long-term goals and targets. It might surprise you how often lower echelons don’t know about these visions, even though the seniors believe they have been clear about them.
If you would have to choose between functionality and timeline, which would it be?
Surprisingly enough most end-users would choose timeline over functionality; “give us the functionality and perfect it later.” It is important to know whether senior executives are sailing with the same boat or not.

Subject Matter Experts

A subject matter expert is not just a well versed user. It is someone with broad and deep industry experience and who knows and understand the industry’s best and worst practices. They can be of great value for your product or service.

There are two things you should be well aware of though:

Sometimes assigned subject matter experts are a bit out of their league – a surgeon won’t be able to tell you much about how nurses are doing their job. Make sure you have an expert on the area you need information about.
Subject matter experts often are very concerned that you, the humble designer, won’t be able to grasp the incredible complexity of their corner of the universe. Do some research on vocabulary, but do not be afraid to let them know their input will be of great value.

Additional questions could be:

Do you have any insights about typical skills of the target audience? What is the variation in these skills? Demographics?
This information may be useful in a later stage, when we will turn to actual user testing.
What different user roles and tasks would you expect in this product?
The answer to this question also helps later in the project, when we need to select user groups for testing.
What sort of workflows do you think we will be seeing in the field?
Some answer will be about the positive practices in their industry; some will be about the negatives. Together they will paint a complete picture that will help the team later during user interviews. Be aware though: do not let this cloud your own view on user behavior later on. Use it as a starting point, nothing more.

Marketing Stakeholders

Let’s share a little secret: most product managers are marketing managers. They are responsible for promoting the brand, identifying new market opportunities and all that good stuff. While most will cooperate with the design team, some view the research we do as a threat to their territory. Make sure you drive home the point that our research serves as an addition to all their work and nothing else.

Marketeers have a lot of value to offer for the design team, so interviewing them is very important.

Some of the specific question I try to squeeze in are:

Who are your major customers today and how would you like this to be different in say 5 years?
This is a very important question as it tells us where the product is heading in the future. Yes, it is long term strategy, but if the product is build with this in mind, its value increases immensely. Try to work out a rough timeline and put this in front of the engineers; if both parties can agree on this, working together further down the line becomes easier.
How does this particular product or service fit in the overall company strategy?
Put everything in perspective. For instance: if this product is meant as entry-level, you need the design to fit the user’s desire to scale-up. Do you see how this may conflict with design the perfect user-experience?
Who are your competitors and what worries you about them? Do you have a competitive advantage?
Competitive research is important and often under estimated. Of course we don’t want to build a copy of their product, but we do want to know about what works for them. Also, from a usability standpoint, we want our future users to feel at home as soon as possible and keep the learning curve as shallow as possible.
If your product was a person, how would you describe its qualities?
The answer you get here will help you greatly when developing a design language for the product or service. It is also useful during interaction design. When presenting a particular bit of functionality, demonstrating how it supports the brand’s values, can be a powerful argument.
What is the current state of the company identity? Are any big changes planned?
Of course this is more geared toward corporate branding than your specific product, but it is still important. Don’t forget to ask for a copy of the style guide and example materials.

Engineering Stakeholders

It’s no secret relationships between engineers and designers can be tense. Engineers fear those “designers” that come up with “crazy stuff because it looks cool.” Some engineers will be reluctant to share information with those they perceive as stepping on their turf; after all, they have been “designing good interfaces themselves for years.”

So, it might take a while, but most engineers I have known are more than willing to let go of the design part once they see you can actually do a better job and, at the same time, make their life easier.

Be aware: never ask an engineer what you can do and cannot do. That’s useless. There is nothing you cannot do with software, given limitless time and resources. Ask what is easy to do and what is difficult; get a feel for where they see bears on the road and be empathetic about it.

What technical decisions have already been made and why?
I had a project once, where actual product design was still unclear, but the framework it would be build on had been decided and was set in stone. The organization involved, which shall remain nameless, had paid € 30k in consultancy fees to figure that out. Naturally, when the product began to take shape, that framework proofed to be, let’s say, less than ideal…
How large is the engineering team assigned to the project? Could you elaborate a bit on the different roles and skills?
Ideally, this also takes shape once the design decision have been made, but quite often you get a team upfront. So, it is important to know what they can do, and of course, what they cannot do. If there is a huge mismatch between the engineering team and the corporate expectations, you need to go back to the product owner and senior stakeholders.
Could you sketch out the current system in place and explain it to me in words I can understand?
Even though I can speak tech quite good, seeing it visually in front of me helps understanding. Heck, this is what we do during workshops and design sprints; visualizing concepts, problems and solutions in order to help others understand them better. As we are only human ourselves, ask for both visual and lay terms explanations.

Final Words

With the focus being put on the user so often, I feel stakeholders are left in the shadows a bit. I see too many teams where stakeholders are seen as the sole responsibility of the product owner. They are not.

If designers claim they deserve a seat at the table, and feel their field should be taken seriously, they should start treating the people at the table respectfully and seriously. Stakeholder interviews are a big part of this and as a designer you should embrace them.

Until next time!