Tone of voice

This is an overview of how we write and should apply to all the writing we do in dxw. It’s an important part of how we present ourselves to the outside world, alongside our new dxw brand. You can find the brand guidelines and all the assets you need in our brand toolkit in the #dxw-brand Slack channel.

Our tone of voice is important because it will have a big influence on how someone reading our content will feel.  This isn’t a set of rules as good writing shouldn’t feel like a tick-box exercise.

We want people who work in the public and third sectors to benefit from our approach and what we learn through working with them. So it’s important that we’re as open and transparent as possible when we communicate. Even better if that persuades others to follow our example.

We want our readers to feel that:

• they can trust us
• we care
• we have lots of experience
• we’re open and transparent about our work

There’s lots of good practice guidance in these Readability Guidelines by Content Design London. To help with readability, it’s also a good idea to use something like the Hemingway app which can help you improve your writing. But remember it’s just a guide.

Overall tone of voice #

Our values should guide how we do things, and how we communicate. So our writing should show dxw as:

• helpful - we explain our work openly and clearly
• positive - with a focus on how we helped others and what we learned
• reliable - we don’t use superlatives but we show that we do consistently good work that we’re proud of
• honest  - we’re open about what we think and our work, including where we got things wrong
• curious - and willing to try new things and improve. As well as helping others to do the same
• determined - and motivated to tackle difficult things and have high standards

We should aim to show our audience the value of our work, not just tell them about it. That might mean showing things like screenshots or video footage of services, outputs or pictures from user research sessions and so on.

No need for formality #

We work with organisations but we should write for the people who work in those organisations or use their services. That means using the words that real people use.

Think about what you’ve written and whether it’s something you would say out loud. If not, then it’s worth changing your language to sound more approachable - more like you.

We also use contractions so we’ll say “we don’t” rather than “we do not” and “I’ll” instead of “I will”.

Use numericals for numbers rather than writing them out so “we built 2 prototypes” rather than “we built two prototypes”.

Some other suggestions to sound less formal:

• swap “commence” for “start”
• swap “enable” for “let”
• swap “ensure” for “make sure”
• swap “key” for “important/significant/essential”
• swap “in order to” for “to”
• swap “utilise” for “use”

Always think about the most straightforward way of saying something. The GOV.UK style guide provides some helpful examples of words you might want to avoid.

Capitalise specific names for a person, place or thing, words at the beginning of sentences, and (if appropriate) abbreviations but nothing else. That includes headers.

(Not) by monkeys #

Your writing will be more readable if you use active sentences rather than passive ones.

For example, “a decision was made to change the name of the service” is passive. “We decided to change the name of the service” is active and also uses fewer words.

A good way to check if you’ve used passive language is to add  “by monkeys” to the end of the sentence. It won’t make sense if the sentence is active. We’ve borrowed this from Monzo’s tone of voice guidance.

The shorter the better #

Shorter sentences are quicker for people to read and easier to understand. Everyone’s busy so there’s no need to write a 30 word sentence if you can say it in fewer words.

Try and aim for most of your sentences to have 15 words or fewer but also try to vary the length of your sentences. Using only short sentences can sound robotic and get a bit boring.

Where we differ from the GOV.UK style guide #

Avoid using hyphens unless it changes the meaning of a sentence.

For example: “a little used-car” is different from “a little-used car” so using a hyphen here makes sense. But if not using a hyphen doesn’t change the meaning like “part-time” and “part time” then leave it out.

A couple more words to avoid:

• platform (unless it’s a train platform)
• portal (unless it’s to another dimension)

Specific names and technical terms #

We use these names and technical terms quite a lot. So be sure to get them right.

Digital Marketplace: the government procurement website should be capitalised as it is a proper noun to distinguish it from other digital marketplaces (like eBay).

dxw: in client-facing and public-facing documents, dxw should be lowercase.

G-Cloud: never ‘G-cloud’ or ‘g-cloud’ or ‘G Cloud’ or ‘GCloud’.

GovPress: not ‘Govpress’ or ‘Gov Press’

multisite: if referring to the feature directly, “Multisite” should be capitalised. If referring to a multisite WordPress setup, “multisite”. Never “multi site” or “multi-site”.

open source: always lower case.

plugin: not ‘plug in’ or ‘plug-in’.

Rails: for the Ruby framework, always upcase. Lower case is fine for the things trains run on.

WordPress: not ‘Word Press’, ‘Wordpress’ or ‘WP’.

Happy writing! And remember that the comms and marketing team are here to help you.

References #

• Monzo’s tone of voice guidance
• GOV.UK style guide
• GOV.UK words to avoid

Last updated: 30 August 2023 (history)