Clarify shared goals face to face.
Sitting down with your stakeholders, asking them four basic questions, and documenting their answers is your best defense against scope creep and conflicting priorities.
Sure, this seems basic, but fundamentals sometimes get overlooked when you get 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, and 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?
Make sure you have a well-defined project scope.
Sometimes, work is coming at you so fast that you cannot promptly produce a requirements document that fully defines the scope and get stakeholders to sign off on it quickly. In such cases, you should consider turning feature requests into agile user stories. Alternatively, when you’re in a crunch, write a brief email to stakeholders making a request, restating their requests, and communicating how you’ll resolve them.
More than anything, 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 forcing all stakeholders to chill out and negotiate.
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 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 essential to completing the work.
- Informed—Stakeholders whom you must notify once you’ve made a decision or taken action.
Numerous RACI resources are online, so I recommend 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.
Make sure white elephants are part of the requirements.
White elephants are more strategic requirements that could be costly to take on—or even intended to take you down. In any case, handling them requires some 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.
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 your users. However, they are also fantastic for achieving transparency with stakeholders and 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 intuitive and informative. But you should be aware of a couple of things if you and your UX team go the agile route.
First, if you follow my advice but are still 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 must also know the magic number of stories you can execute during any sprint. If it’s one story for 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 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 and give them a better understanding of the design process. This will also provide more peripheral stakeholders a stake in what is happening and encourage the team to execute your designs properly.
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. (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. Show them as soon as you have learnings to present to the team. Even if you give your team a status update, this will indicate your progress to the appropriate stakeholders. My rule of thumb is that it probably has been if there isn’t anything scheduled on my calendar, and it feels like it’s been a while since I’ve shared learnings with my team.