UX & Managing Stakeholders

The stakes may be higher than you think

Don’t you hate it when you watch a show and the good guys spend a whole lot of time fighting amongst each other instead of fighting the bad guys? I’m looking at you Umbrella Academy and various superhero team-up films. Yes, I get it — it’s part of character development. While ‘hate’ may be too strong a word, for me, such scenes get old pretty fast. People, you have something important to do, so get around to doing it already!

Now, how much worse would it be if we had to experience that in real life while working? The stakes may not be as high as in The Avengers, but we don’t have the plot or ‘destiny’ to ensure that our work will be completed successfully.

Multiverse of Madness: The problem

On most occasions, we are greatly tempted to concentrate on managing the client. The customer is king, after all. Yet, in the course of serving the customer, there are other stakeholders involved that can help determine whether the project is done well. These stakeholders could be the project team, clients or even users.

Moreover, the client may not be just one person, but a collection of individuals who might not always see eye-to-eye. So, inevitably, we’ll need to manage different people in the course of our work, both internally and externally.

As UX designers, there is the added complication that the focus of our work tends to be on the users of the product or platform. We might find it difficult enough to balance both the users’ needs as well as the client’s requests. Now I’m saying it’s not just one versus the other — we need to take into account the different interests of various stakeholders involved. How might we accomplish that?

Civil War: A case study

Recently, I worked on a large project as an external consultant. I had been brought in to run the usability testing and design iteration phases for a website.

The client was made up of a committee of decision-makers, which sounds like it might be challenging to get a consensus and buy-in from all of them. However, things actually went quite smoothly. I can usually understand what clients want, picking up on differences in perspectives between individuals, and foresee how they might react.

This is more an art than a science, requiring some perceptiveness and the ability to remember what each person has said. When doing this, you should distill whatever insight you’ve picked up into a list of wants and concerns for each individual that you can always refer to.

An example list of stakeholders and their wants and concerns during a project phase. I tend to keep all this info in my head, but it could be useful to create a table like this to organise it.

This is a method for stakeholder management that I’ve been using, and it worked well for this project at first. It helped me prepare responses to client questions and make sure that design decisions were aligned with the various clients’ objectives.

However, client management is not the whole picture.

As an outsider, I didn’t have visibility on everyone in the organisation who had some interest in the project. Furthermore, we were all working remotely and there was no official project manager coordinating and being the bridge between different parties — one lesson to be learned on what not to skimp on for a project. So when two internal stakeholders I was unfamiliar with showed up halfway, raising unexpected objections, I was taken by surprise.

I had not had the opportunity to understand what their objectives were and couldn’t prepare a good response beforehand. Therefore, it took a bit of effort to work through misunderstandings about the design process and assure them their concerns had been addressed along the way. The issue was resolved in the end, but not before quite a bit of tension had been created.

The Quest for Peace: Solutions

After the incident, I reflected on how I could improve in managing stakeholders. While a disaster had been avoided, under different conditions, things could have gotten out of control and resulted in serious delays.

For that project, not everything was within my control, but if I did have better access to information, what more could I have done to preempt such a situation?

I started doing some research and found a couple of useful methods, including the ever-popular RACI, which can also be used with key actors from the client side. My favourite, however, is stakeholder mapping, which would allow me to create a neat chart like this:

A power-interest matrix plotting stakeholders along the two axes of their power and level of interest. Source: Nielsen Norman Group.

The idea is some stakeholders will have more impact than others, and different stakeholder management strategies need to be applied depending on the level of impact they can have.

To fill up this chart, we need to assess each stakeholder’s potential to impact a project, both positively and negatively. Then we would plot our stakeholders on the power-interest matrix above to help us see what strategies we need to use to manage each of them, as labelled on each quadrant.

Applying this method in the early stages of a project would create a framework for any subsequent management methods and ensure that we never go into a meeting with stakeholders blind. It’s the perfect complement to and starting point for my own method of stakeholder management.

Endgame: Convincing the stakeholders

Now we know who we’re dealing with and what we might need to look out for during a project. But as issues are foreseen or as they come up, we still need to do something about them, whether it’s convincing stakeholders or allaying their concerns.

Luckily, the UX process itself can help with that. With user research, we could use the gathered insights to justify our design decisions. A competitor analysis could also enable us to evaluate competitors’ designs and back up our recommendations accordingly.

Of course, there are other methods outside the realm of pure UX that we need to get a handle on, such as being able to show the business value of our solutions. And, if it comes down to it, we might just have to use our people skills to reassure stakeholders and, if need be, seek a compromise.

There are too many methods for influencing people for us to delve into here, but the important thing to note is that this is the second part to stakeholder management. The first part is essentially intelligence gathering, while the second involves actually using that intelligence to achieve the outcomes we want.

Love and Thunder: The conclusion

To sum up what I’ve learned about stakeholder management as a UX designer, first, we need to care about who they are (in terms of their roles) and what they want. Find these things out beforehand, as much as possible. Then, when the time comes to get their buy-in, we need to hit them with the evidence and with our skill at persuasion — a bit of shock and awe, so to speak.

Being good at stakeholder management means we can do our work more effectively and spend more time creating good UX rather than fighting other people. Generally, UX resources don’t seem to discuss it in depth, but it’s a crucial part of the job nonetheless. It might even be a way to distinguish ourselves as UX designers and professionals.