Empathy for the stakeholder
Content designers need to balance our deep understanding of user needs with empathy for the stakeholders on our projects.
By Alex Knights
Alex is a content designer and content strategist. He has worked with countless subject matter experts and senior stakeholders in government, public services and book publishing over the past 20 years.
Balancing user needs and business needs
Start with user needs. So goes the first of the government design principles, instructing service designers to ‘have empathy for users’. And it’s generally second nature for content designers to practice empathy for the user. If we’re lucky, we’ll be working with user researchers who’ll provide us with insights about the experience of the users we’re designing for. If we don’t have that luxury, we’ll draw on our own research, our understanding of best practice, our imagination and our instincts.
But there are other needs we start with that we ignore at our peril. These are the needs of the business or organisation responsible for the content. And the arch proponents of these needs are stakeholders. Sometimes, in our quest to develop content that truly focuses on the user and the actions they need to take, we can find ourselves blocked or thrown by the needs of stakeholders. But to succeed in the projects we’re working on, we need to balance our understanding of users and their needs with another kind of empathy – empathy for the stakeholder.
See the government design principles (opens new tab).
What stakeholders want
Stakeholders within an organisation are many and various – they may be subject matter experts or policy people, senior managers responsible for corporate strategy, or comms officers raising awareness of the organisation and fending off threats to its reputation. These holders of stakes sometimes hurl them across our path towards perfect user-focused content. And, indeed, they sometimes see content designers as blockers to uploading information they need to publish to the internet.
“These holders of stakes sometimes hurl them across our path towards perfect user-focused content.”
In the public sector, a classic difference of views is around the use of plain English and technical terms for specialist users. Subject matter experts or policy teams object to the content designer’s proposal to rewrite existing guidance in plainer language, not necessarily because they’re against the idea of making content more accessible, but because they’re concerned about confusing or alienating their audience who are ‘used to things the way they are’. Or they feel that plainer language risks losing certain technical meanings or exposes the organisation to the possibility of a legal challenge.
To counter this, the content designer can deploy various arguments – users could be new to their sector or new to their role; users could have a cognitive impairment or other disability, or English as a second language; research shows experts prefer simpler language; we don’t want to remove technical terms, we just want to explain them. All these arguments are valid.
But before we argue for the user, for clarity and for accessibility – which we must – we can also take a moment to understand the stakeholder’s perspective. They don’t want the organisation to be at risk legally or fail in its strategic requirements – neither do we. They don’t want to confuse users by oversimplifying concepts or to undermine their trust by going off message – neither do we. But these are things we could inadvertently cause to happen if we’re not careful, so the stakeholder has a legitimate cause for concern.
Pragmatically speaking, we need our stakeholders to be on board with the project so that we can indeed get something published and help users with whatever they’re trying to do. The stakeholder may want to capitalise a word that does not need capitalising for any earthly grammatical reason – but what is the cost of winning that argument? And is the user really any better off? We need to pick our battles and meet our stakeholders in the middle. After all, it’s usually the stakeholders – the subject matter experts, the policy teams, the senior managers – who take ultimate responsibility for the content when they sign it off for publication.
What stakeholders offer
Subject matter experts bring their knowledge, experience and, hopefully, a deep understanding of the users and the process they need to follow. They’re good at knowing what users are ‘doing wrong’ – for example, where they’re ‘forgetting’ to do a certain step in the process. And they’re good at knowing where users are getting frustrated – they may be getting lots of feedback about it. SMEs don’t always seem to see beyond their internal ways of working, but even that can be useful for understanding why existing information is the way it is. And, of course, SMEs do the vital job of ‘fact checking’ and validating content – even if they do have a habit of rewriting content when you’ve kindly asked them not to.
“They’re good at knowing what users are ‘doing wrong’ – for example, where they’re ‘forgetting’ to do a certain step in the process.”
Meanwhile, the comms team will advise when to publish something for maximum attention, what the risks are of publishing something prematurely and what might provoke unwanted attention. Senior stakeholders sanction projects and teams and the budget that underpins them. We need these people to hold their stakes!
Five things content designers can offer stakeholders
1. Hear them out
Stakeholders have their own pressures and priorities. Hear them out if they bring up concerns in a meeting – or offer to have a separate meeting with them. They necessarily have a deeper understanding of how things work and, perhaps, what has been tried before and failed. The project might be challenging existing ways of working and might even feel threatening. You may move onto another project, whereas they may continue to be responsible for the thing you’re working on now.
2. Challenge and reassurance
If you’re recommending a certain approach to stakeholders, talk them through the evidence you’ve gathered to make your judgement. Give examples of other guidance or services where something similar has been put into action. You could emphasise that content isn’t set in stone. Let’s make a hypothesis about a change, test it and review whether it has made a positive difference. Stakeholders will probably be happy to join a review session.
These techniques can be used to challenge existing content and ways of thinking – but can also be a source of reassurance. Show stakeholders that you’re taking informed decisions to make changes and that you’re taking responsibility to assess whether those changes have been effective.
3. Passion and enthusiasm
As you start out on a content project, give stakeholders the sense it will be an interesting and enjoyable experience. Discovery workshops can be good for this. Stakeholders generally enjoy the chance to step back and consider things from a user’s perspective.
If you feel strongly that something needs to change (because of the evidence, of course), it’s usually ok to let that passion come across. You may have identified inherent problems with a process that stakeholders have wanted to change for years, and you may be able to bring the fresh take needed to finally get something done. Nevertheless, temper this with some humility about what stakeholders know that you don’t. If they tell you something has been tried before and failed, you may have to accept that changes and improvement will be more gradual and incremental.
4. A chance to learn
It can be helpful to see your interaction with stakeholders in terms of a skills exchange. I’ve worked for various organisations, public and commercial, developing guidance on all sorts of subjects – and this always brings a chance to learn about things I didn’t know before. Anything is interesting… up to a point! Meanwhile, it’s unlikely that stakeholders have spent time learning about content design and user experience, and they’re usually keen to learn more. They also do things online and, outside of their work sphere, would probably have little tolerance for filling in an Excel form or reading a PDF on their mobile phone. Show them video snippets of where users are struggling, explain to them how to use Google Trends, or invite them along to your next show and tell.
“It can be helpful to see your interaction with stakeholders in terms of a skills exchange.”
5. Highlighting the risk of doing nothing
It’s typical for stakeholders to see things in terms of risk, but not always the risk of inaction. Stakeholders can be liable to wanting endless rounds of fact-check – one stakeholder wanting it this way, another that way. Or they’re waiting for a small point of policy to be settled before they feel they can sign off a new draft of guidance, even though an out-of-date page of guidance remains live, confusing users and perhaps even putting them off all together. Trying to get stakeholders to think in a more agile way is challenging – but finding evidence that the status quo is having a negative impact might just be the way to get things moving.
Chatbots on my mind
I’ve had chatbots on my mind of late. What content person hasn’t? But, right now, us folk in content can only really say ‘let’s see’ to the role that AI is going to play in our future, and whether the mathematical models that underpin this automated language generation are going to one day simulate consciousness. But I’d argue that our ability to empathise with our users and our stakeholders – each with their own set of behaviours, needs, biases and expectations – and from this understanding to develop content that satisfies user needs and organisational needs is, to my mind, something that sets us apart from the bots. For now.
Need designers to engage with your stakeholders, enthuse them and bring them along on a journey with you? Contact Scroll