Most of the criticism I’ve seen of the concept of tone focuses on three main points:
1. Tone = terrible content
People try to add tone and end up with terrible content as a result. We’ve all seen them, the cutesy 404 messages and glib error messages – ‘Oops, the hamsters that power that page seemed to have escaped the wheel’ – that don’t actually help the reader.
2. Tone = common sense
There’s no need for tone guidelines, because tone is common sense. Of course you’ll shift your writing for different scenarios – it’s what we all do whenever we speak.
3. Tone = assumption
To adopt a tone, you need to assume something about how your reader is feeling. And assuming can make an ‘ass’ out of you and your content, because there’s a big chance that you’re wrong.
So here are my ‘yeah, but no’ reflections on those three valid points.
Tone ≠ terrible content
I’d argue that the examples that get shown in this context are all examples of people trying to add ‘delight’ to a user experience through tone and doing it badly. And they tend to be moments where the content should focus on creating clarity, not eliciting an emotional response.
But tone has a place at other moments and in other kinds of content. Homepages, landing pages, product pages, emails, social media – these are all places where tone really comes into its own. And voice guidelines should be for all the content an organisation creates – not just the things the content designer or UX writer gets their hands on.
Tone ≠ common sense
I want to build on my last point that voice and tone guidelines are for all content. In the vast majority of organisations, some/all content is being written by people who aren’t content professionals. No, that’s not ideal. But it’s probably always going to be the case.
In my experience, tone isn’t common sense for many people – especially those who aren’t from a content background. But once they understand the concept – and have guidelines to support them – they get it.
Tone = assumption
This point I agree with, and I’ve made some changes to my approach to tone as a result. Adopting tone often relies on assumptions about what the user might be feeling. And this can go wrong.
To mitigate that, you need to develop your tones based on user research and test whenever you can. And if you’re still not sure what the user might be feeling? Don’t make assumptions: dial it down, keep it neutral, focus on clarity.
I’m thankful to see this discussion and criticism – it helps push our discipline forward and challenges us do better. But for now at least, I’m going to keep tone as a part of the voice guidelines I create.