How to convert sceptical UX stakeholders to allies

Image from rawpixel.com

I have often been asked how I go about persuading sceptical stakeholders (which I’ll abbreviate to SSH) that UX practices including research are the right thing to do – and that they are effective. The alternative is usually touted as either ‘just draw what I’m telling you’ or ‘if you’re so good at this why do you have to take all this time and money to figure out what to do’.

I’ll say right up front that the single most effective method that I’ve found is to get the SSH to attend some user research in person. The SSH will have their own preconceptions of what will and won’t be effective and will often believe they intimately understand how customers think. You can argue and present an alternative view to them based on experience, previous research, numbers, whatever – but ultimately it just comes down to your opinion (sure, with some backup) against theirs. There’s no emotional or visceral connection for them.

Once the SH watches a real customer struggling with an ‘easy and obvious’ interface, or articulating a completely different rationale and way of thinking about what they are doing from the SSH’s assumptions, then that emotional connection is made. Either they choose to accept what they’ve seen and heard or they choose to ignore it. If the latter it’s a different ballgame, but any reasonable person will concede that they have learned something useful and new. I would add also that if for example you are doing 1-1 depth interviews for usability, then the SSH needs to attend at least 3 sessions and preferably more. They need to see that the issues arising are not the whim of a single atypical customer. If they see that a particular issue is raised by even two or three people then the message starts to sink in.

Even so, there can still be some peripheral objections about the methodology or the way the questions were asked, or that the questions didn’t get at the heart of the matter. So there are some things to do to ensure that the viewing experience has the greatest impact. These can be summed up in ‘involve the SSH all the way through’.

Firstly, make sure you understand not only the business objectives of that SSH but also their personal drivers. I’ll take it as granted that you’re balancing business objectives with customer needs in a design, but if you want to take a SSH on the journey with you then you need to know if they are dealing with a similarly sceptical boss they also need to convince, or if they are new to their role and feel they need to prove themselves quickly – or whatever. This understanding will inform your conversations and the supporting material you provide them with.

Even if the SSH has some ideas about design it may be that showing them some options or introducing technical constraints will sow some seeds of doubt about their own invincibility. I’ve found a workshop with a limited number of people from commercial, engineering, design (and whoever is needed – legal, PR etc) can be effective. The idea again is that it’s not just you arguing the toss but a session of domain experts focusing on the issue at hand, working through constraints, enablers and options. At the end of the session there may be outstanding actions for people to go away and find out about – there may aspects of business process, technical possibility or law to be clarified before significant further steps can be taken. In a small organisation this session may just be a few people round a table – in a large organisation it could be a bigger meeting.

It’s important throughout all this to present a humble face. Whilst you may be convinced that a given approach is the right one you need to show that you are listening and considering alternatives – just as you are asking others to do.

When it comes to planning some research then the SSH has to be included in agreeing the objectives, method and conduct of the research. You don’t want them to have that wiggle room afterwards. If the SSH has agreed to all these things and been given ample opportunity to voice any objections or issues then they will be more committed to the process. This doesn’t mean that you have to do everything they ask. You still need to be the expert running the show – the person who knows the right way to do things. So you need to find a way to incorporate their input in an appropriate manner. Sometimes it’s necessary to include a design option that you are convinced won’t work just so that the SSH can see it for themselves and to show that you’re not trying to ‘rig’ the outcomes.

If you look at resources on stakeholder management you’ll find plenty of other techniques that you can use alongside what I’ve described here – and it’s a good idea to do so. Nevertheless if you make sure you are engaging in constructive dialogue, showing that you are listening and exploring options, and involved the SSH all the way through in the planning and execution of the research, then you’ll find it will take you a long way to turning that sceptical person into an engaged ally.