While we might not think of stakeholder management as a key UX skill, it is integral to our work. So much so that it occasionally surprises me that we don’t all approach stakeholder management with the same rigor that we do user-centered design. This becomes clearer when we consider the frequent headaches that are associated with poor stakeholder management—from having product-team members perceive User Experience as an impediment to delivering products to losing our UX budget and headcount.
In the course of my work as a UX designer, I’ve been doing a lot of thinking and experimenting with how to provide the most transparency to my stakeholders, while also keeping the scope of my design work realistic and manageable. I’ve been able to consolidate my learnings from experience down to six major points that I’d like to share, in the interest of professional growth.
Before diving in, I need to say that, even though the putative subject of this article is the management of stakeholders, the intent of the techniques that I present here is neither to corral nor obstruct. When using these stakeholder-management techniques, think of your job as a servant stakeholder whose job is to create transparency, head off conflict, and maintain your own sanity as a UX-design professional. Let’s get started.
1. Clarify shared goals face to face.
Sure this seems basic, but fundamentals sometimes get overlooked when you’re getting a lot of conflicting information from various stakeholders who are ostensibly part of a product team. Sitting down with your stakeholders, asking them four basic questions, then documenting their answers is your best defense against scope creep and conflicting priorities. Ask stakeholders the following questions:
What is the purpose of the product?
Who is the product for?
What is the desired outcome of the project?
Who is responsible for that outcome?
2. Make sure you have a well-defined project scope.
I know this is really obvious, but there are times when work is coming at you so fast that you simply cannot produce a requirements document that fully defines scope in a timely manner and get stakeholders to quickly sign off on it. In such cases, you should consider turning feature requests into agile user stories. Alternatively, when you’re really in a crunch, write a brief email message to stakeholders making a request, restating their requests and communicating how you’ll resolve them.
More than anything else, having a well-defined scope is a great shield against take-charge stakeholders who might swoop in at the last minute and disrupt the team’s work by asking for more. Participating in scoping is also a good way for less assertive personalities to learn to push back when requests come in that are unreasonable or would be disruptive to a project. In my experience, just saying something is out of scope is like putting up a brick wall and forces all stakeholders to chill out and negotiate.
3. Stack-rank responsibilities to avoid conflicts.
It is always good to document who is the most important stakeholder at a given point in a project and for what purpose—both so you and your team know who to report to and so you can deflect responsibility for things that are not part of your job description. I prefer the RACI method of identifying roles and responsibilities. This method is very simple and flexible and lets you group stakeholders by whether they are:
Responsible—The stakeholders who own and must take action to solve a problem.
Accountable—The single stakeholder who has approval or veto authority and is answerable for the outcome of a project.
Consulted—Stakeholders who are subject-matter experts and hold information that is essential to the completion of the work.
Informed—Stakeholders who you must notify once you’ve made a decision or taken action.
There are numerous RACI resources online, so I refer you to them for more in-depth knowledge about this method. However, by understanding the shifting pecking order for a project, you can better anticipate where conflicts may occur and get yourself out of the line of fire.
4. Make sure white elephants are part of the requirements.
White elephants are more strategic requirements that could be costly for you to take on—or even intended to take you down. In any case, handling them requires some advance planning. Sometimes, for the good of the project—and your team’s mental health—you may need to misdirect a demanding, take-charge stakeholder--to prevent him or her from burdening you with a white elephant.
If you are scoping a project and want to be proactive about limiting such a stakeholder’s negative impact on a project, you can create a line item in the requirements that you know the team will take out later—or plan to add a requirement later. This approach can be either additive—adding something that will go into the final product, but isn’t consequential to the overall business goals—or subtractive—planning to take something out of the final product.
5. Take advantage of user stories for stakeholder management.
Working from agile user stories can be a hassle for UX designers if it feels more like you’re designing for the developers than for your users. But they are also fantastic for achieving transparency with stakeholders and for serving as a barrier against too many ad hoc requests. For maximum efficiency, set a reasonable number of user stories to tackle, then post them publicly, along with a progress indicator. I prefer displaying them on a Kanban board, which tends to be both intuitive and informative. But there are a couple of things you should be aware of if you and your UX team go the agile route.
First, if you follow my advice, but you’re still just designing in response to stories, that is symptomatic of over-ambitious expectations or an unrealistic timeline. If either of those things is the case, it is incumbent on you, the UX designer, to put your foot down and renegotiate the backlog deliverables. You also need to know the magic number of stories you can execute during any one sprint. If it’s one story for each of the next two sprints, be upfront about it. Agile focuses on deliverables, not arbitrary deadlines, so take advantage of that!
Second, you will have an easier time of managing stakeholders if you designate time for co-design during at least a couple of early sprints. By designing with other stakeholders, you’ll help build empathy among team members, as well as give them a better understanding of the design process. This will also give more peripheral stakeholders a stake in what is happening right now and encourage the team to execute your designs properly.
But What If You’re Not Working in an Agile Shop?
For those of you who are not working in an agile organization, the same principles still apply. You can duplicate this approach with just some minor adjustments. First, I recommend your using some type of tool to track and broadcast your progress. Both Asana and Trello are really good options.
Second, you need to have a basic process that you can reliably replicate to prevent your constantly reinventing the wheel. Treating each situation as completely novel and unique impairs transparency with stakeholders. This would cause them to question the validity of your work—and, in turn, significantly affect both your professional credibility and your ability to advocate effectively for User Experience on your team—and will, ultimately, stress you out!
The solution is to employ Lean UX methods for research, design, and validation. As a designer, if you are not practicing agile UX, learning to employ Lean UX methods is essential. I recommend that you buy the book Lean UX: Designing Great Products with Agile Teams, by Jeff Gothelf and Josh Seiden. (I am not in any way affiliated with Gothelf or Seiden. I simply think that the authors provide one of the most concise, easy-to-follow roadmaps for you to start quickly employing Lean methods.)
Having a solid process in place that UX professionals on your team can follow makes your work infinitely easier once you get the hang of it. I think you’ll find that it’s the difference between being a cog in a machine and providing leadership by example.
6. Never withhold or hoard knowledge.
UX design requires transparency, and transparency starts with you. As a UX professional, you should never withhold any knowledge from your stakeholders. (Of course, this advice applies to more than just stakeholder management.) In the context of this article, I’m referring specifically to the problem of keeping user-research findings in the head of a single researcher who represents the user during team discussions. In his article “7 Deadly Sins of User Research”, Dr. David Travis refers to this issue of hoarding research findings as obscurantism.
The solution is very simple. As soon as you have learnings to present to the team, present them! Even if you just give your team a status update, this will provide an indicator of your progress to the appropriate stakeholders. My personal rule of thumb: if there isn’t anything scheduled on my calendar and it feels like it’s been awhile since I’ve shared learnings with my team, it probably has been.
As I mentioned earlier, I’ve found the techniques that I’ve described here to be extremely useful in getting work done that meets or exceeds my stakeholders’ expectations—as well as in building great relationships with stakeholders.
Of course, you don’t need to use all of these techniques at once. The stage of your work is a major factor in deciding which techniques to employ and which to leave on the table. Please employ these techniques in the ethical spirit I’ve intended.
I hope you’ll share your thoughts in the comments! Especially if something I’ve suggested hasn’t worked for you, let me know. Maybe we can help each other to think it through.
Jacob specializes in designing large-scale, SaaS solutions. At CDK Global, he led UX strategy and design for a suite of mobile and SaaS communications applications and communications-intelligence products. He is particularly interested in business-model validation through UX research. Jacob is a NN/g certified UX Designer. Read More