Get hands-on practice in all the key areas of UX and prepare for the BCS Foundation Certificate.
There are few things more likely to make your design or UX project difficult than a poorly conducted stakeholder meeting. Structuring your stakeholder interview around a few simple techniques will ensure you get off to a good start and set you up for success.
Photo by Stefan Stefancik on Unsplash.
Though it may consume two of hours of your life, involve people saying lots of words, and require much watching of PowerPoint, when distilled to its barest essentials, the typical stakeholder meeting often goes something like this:
Client: “We need you to design a new wibble.”
In this scenario, design teams, whether internal or external to a company, often end up simply designing what they are asked to design, or rolling out the usual ‘one-size fits all’ usability test. Project requirements arrive by decree from on high and go unchallenged. The trail of data and decision-making linking the thing being designed to the potential customer is a tenuous one, or is non-existent.
Designers and UX-ers find this approach frustrating and disheartening because it sells them short. We know we can design the best wibble imaginable, or carry out the best usability test: we just don’t know for sure whether a new wibble or a usability test is really what’s needed.
There’s a better way.
I’d like to share with you an effective and structured technique that is guaranteed to flush out the information you need to properly diagnose your stakeholder’s needs and help them be successful.
The approach is based on my favourite, and ‘most thumbed’, business book, Let’s Get Real or Let’s Not Play by business development consultant Mahan Khalsa. In it, he describes some simple steps designed to give a new project opportunity a bit of a shakedown.
We’ll look at each step in turn and see what we can learn from Khalsa’s masterful understanding of how to help stakeholders and clients succeed.
But first an important rule upon which these steps are predicated: No guessing!
We too often think we have understood a stakeholder’s needs properly — especially if we work for the same company — when we haven’t quite grasped something. We often make assumptions without even realizing that they are just assumptions. We may assume that the design or research requirements have been derived from reliable information and careful decision-making. We may hesitate to ask the right questions if we think it makes us look like we don’t know what we’re doing.
But it’s important not to guess, or to think that the answer to your question doesn’t matter. It will matter at some point during the project. Not knowing may result in you making the wrong design or research decisions, and by then it may be too late. If you don’t understand something in the stakeholder meeting, the chances are others don’t understand it either. So avoid guessing. “Supposing is good,” advised Mark Twain, “but finding out is better.”
Here’s what to do instead: Move off the solution.
Your stakeholders really only want to talk about solutions. “We need a new design for X” and “Can you do Y?” are solutions. Most stakeholders are looking for a quick fix, or a magic bullet, because they have already self-diagnosed their needs. The formal ‘Request for Proposal’ (RFP) works this way. A typical RFP offers little real insight into the client’s needs and usually assumes no one will ask any questions. Face to face discussion is actively discouraged. The client has already decided what needs to be done, has written down the solution, and now just wants someone to deliver: “A pound of design please and two bags of usability. Thank you very much.”
It’s possible, of course, that your stakeholder has indeed arrived at a correct diagnosis, but the real difficulty lies in the fact that they may not know how your design or UX process works, so they don’t know what you need to know before you can start thinking about designing a solution. We can get ourselves in a fix if we allow ourselves to get swept along by the promise of solutions. After all, we love talking about what we can do. Talking about solutions is what we do best. It’s easy. Besides, it’s what the stakeholder expects the meeting to be about.
So why avoid talking about solutions?
Because we don’t know what the problem is yet. Solutions have no inherent value. They can’t exist in isolation from a problem. The fact that stakeholders think they can is because the word has entered the lexicon of meaningless business jargon. But if we’re going to create a real solution, there must be something to solve. In Khalsa’s words, the solution must alleviate some pain that the stakeholder or company is experiencing, or it must result in some gain that the stakeholder or company desires.
The one thing you can bank on is that the stakeholder will bring the solution (design a new X) to the meeting table. Respond by shifting the focus. Change the direction of the conversation away from solutions and, ever so subtly, take control of the dialogue:
The stakeholder may respond by giving you a list of problems, or may go all vague on you and wander off into a pointless ramble. Bring them back to your question.
“Thanks for describing the general situation. Let’s get a bit more specific. What particular problem have you identified that you think a new X will solve for your customers?”
So don’t get trapped into talking about the solution.
Next, have the stakeholders generate a quick list of issues. The items you write on the whiteboard should describe a specific problem or a desired result or outcome. Don’t dwell on any one issue at this point — you don’t know which issues are important yet — and don’t allow the conversation to spiral away from you as stakeholders debate among themselves. Just focus on creating the list. If you are working with a group of stakeholders, you can ask individuals to write down what they believe the main issues are on sticky notes, then have them place them on a whiteboard. That can prevent the meeting from becoming a free-for-all.
As the list unfolds, keep pushing for it to be a complete list:
“What else are you hoping X will address?”
Don’t start discussing any issues just yet. When the stakeholders have exhausted their input, if your own expertise is telling you something is missing, you can prompt with:
“I notice no one mentioned anything about (e.g. improving ease of learning). Is that an issue for you?”
Next, you need to know which issues matter the most. Sometimes the stakeholders will easily identify the main issues. Other times they may say, “All the issues are important”. Respond to this by acknowledging that you want to understand all of the issues, and then ask,
“Which one would you like to talk about first?”
“If you could make progress against the issues on this list, and nothing else, would you have a solution that exactly meets your needs?”
If the answer is no, there’s still something you’re not being told. Find out what it is and add it to the list.
Now you’re ready to ask a question that may take your stakeholders by surprise, so be prepared for hesitation, uncertainty, or even a long pause, as you look at the list and ask:
“How do you know these are problems?”
Cue hesitation, uncertainty and a long pause.
Our questions about evidence are likely to result in one of four possible outcomes:
It goes without saying that we would like to see hard evidence. But if it doesn’t exist, or if the evidence is weak or unreliable, all is not lost. In this event, we can offer help to get the evidence. We know how to do design research; so we can put feet on the ground and collect real evidence based on real user behavior. Or we can help search for existing evidence within the company. What we can’t do is brush the matter aside and just wing it. No guesswork, remember.
We not only want evidence that the problems are real — we also want to know how important the problems are and how big an impact solving them can have:
Once we get into this kind of discussion, if the problems are important and the impact is big, we can present rough calculations like this:
“You’re telling me that overall, returns cost you $12 million a year. But only 25% of these products are actually faulty: the rest are returned because they are just too difficult to use. Our UX work will eliminate the usability problems that are causing the returns. This will save you $9 million a year, and $45 million over the next 5 years. Let’s get started.”
What if the problem is not very important or the impact will be small? Khalsa has a clever technique: Remove the solution.
“What if you did nothing?”
Here’s where you can pull back a little and let the stakeholders convince themselves that the project is important. Remember that people like to buy, but they don’t like to be sold to. You can help move the discussion along like this:
This may seem like you’re playing hard to get and it may feel counterintuitive, but if the opportunity is really not that important to the stakeholder then even your best solution will fall flat, and it might be in the best interests of both parties to step back and revisit the opportunity at a later time.
Once we have a clear understanding of the problem, some evidence that it is real, and a measure of its importance, we can start to expose the background and history and some of the constraints and obstacles we may encounter once we get started. Ask questions like:
At this point you may get responses such as:
Khalsa calls these good constraints. They are good because they used to exist but don’t anymore. Or you may get responses such as:
If you hear these kinds of responses, you must ask:
And it’s OK to say,
“From what you’ve been saying, it sounds like some of these obstacles still exist. What do you think we should do?”
Remember, your objective is to help your stakeholder find a way through to a solution and to help them be successful. This may involve helping them trouble-shoot whatever obstacles are in the way.
This approach to an initial stakeholder interview will help put you in control of the meeting and get you the information you need. But a word of caution: don’t catch your stakeholders off guard. Your objective is to get information, not to expose the fact that they haven’t done their homework.
I always give clients advanced notice of the kind of meeting I’m going to conduct, and the kinds of questions I’m going to ask, so they can do some preparation if necessary. This serves two purposes: first, the meeting will be pointless if the stakeholder can’t answer my questions. And second, this ensures I’m going to be meeting with the right people. These will be decision-makers who are accountable for the project’s success, and who have authority to make decisions and manage the budget.
I’ve tried these techniques in my own stakeholder meetings and not only do they deliver the goods, and make for a very productive meeting, but they also create a strong first impression of my ability to help solve the problem, and leave the stakeholders feeling confident that I know what I’m doing and that they are in safe hands.
Then again, there’s always the approach I mentioned at the beginning. You could just ‘play nice’ and say “OK” and do what the stakeholders ask you to do. Good luck with that. Your stakeholder meeting will probably go something like this.
Dr. Philip Hodgson (@bpusability on Twitter) has been a UX researcher for over 25 years. His work has influenced design for the US, European and Asian markets, for everything from banking software and medical devices to store displays, packaging and even baby care products. His book, Think Like a UX Researcher, was published in January 2019.
Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details
Our most recent videos
Our most recent articles
copyright © Userfocus 2021.
Get hands-on practice in all the key areas of UX and prepare for the BCS Foundation Certificate.
We can tailor our user research and design courses to address the specific issues facing your development team.
Users don't always know what they want and their opinions can be unreliable — so we help you get behind your users' behaviour.