Create a great style guide that people use

Clare Elliott is a content designer. She worked at Deloitte Digital for nearly 10 years, specialising in designing content for financial services. In this post she talks about how to manage specialist language using a style guide – what goes in, what stays out and how to bring the organisation with you.

I have worked as a content designer in the public sector and financial services. These are very different worlds that have a lot to learn from one another! And where a style guide can do so much. 

A style guide can:

  • demystify, engage and communicate the breadth of a tone of voice,
  • go beyond whether you use ordinals and contractions and make your tone live and breathe through 100s of relatable examples. 

When a style guide is loved and well-used, both in and outside of a content team, it’s a big win. It shows that the whole company cares about:

  • maintaining a consistent tone,
  • documenting what certain words and phrases mean for everyone’s benefit.

Some style guides include  ‘A to Z’ lists of commonly used terms, with guidance such as capitalisation conventions. 

A style guide entry might look like this:

account number 

Always all lower case, 2 words, no hyphen.   

You could also consider tone of voice in your style guide. For example, under the subheading ‘customers’ you could have an entry like this:

existing customers

Customers who already hold our bank accounts. Say ‘If you’ve got an account with us already…’ or ‘Already with us?’.

Sector-specific language and jargon 

Many sectors develop their own language and jargon. It can make sense to the people working in the sector, but not always. And it's often difficult for people outside that sector to understand. I’ve seen financial language be a problem for colleagues and the people using our services. 

I see a lot of my colleagues default to using initial caps and using more words than necessary. This might be because finance is highly regulated. There’s a lot of jargon and legalese. I work with people who will often want to use capitals for Account Number, Account Holder, even Mobile Phone Number. They feel capital letters add emphasis, and highlight that things are important. 

My counter argument is that a more natural, warm tone will sit better with users. This means:

  • reducing jargon,
  • more lower case letters, 
  • a more conversational style. 

I ask stakeholders if they would capitalise these terms in a message to a friend. The answer is usually ‘no’. And your style guide is a great place to document battles lost and won.

What goes in and what stays out of your style guide?

A style guide must include the words, and phrases your brand voices use to communicate externally. If you invite colleagues to tell you what information they need in a style guide, they’ll be more likely to use it.

You can do this by:

  • speaking with people from across your organisation to get their thoughts on company language and look for themes and commonalities,
  • pairing with subject matter experts to make jargon as clear as possible makes sure your entries are clear and correct,
  • testing descriptions and asking for feedback.

Ownership

I think the overall owners of a style guide should be the content design team. This means they are responsible for writing entries and checking they’re up to date. 

In my current team, we’ve divided up the alphabet between us. It’s a resource for all, so any employee can get involved. We welcome:

  • new entry ideas, 
  • opinions on draft entry ideas, 
  • suggested updates, 
  • any other feedback.

A style guide is a fantastic excuse to tell everyone about the content team – the work they do, the resources they have and the collaborative way they like to work. 

Some ‘extra’ entries I also like to include 

Agile terms 

We don’t use these externally. SCRUM, 3 Amigos – the terms for Agile go on and on – and can be interpreted differently from place to place.

Entries where you admit you don’t have the answer yet

Letting people know something is being tested shows the content team have it covered. 

For example, when we were deciding how we would write open banking, I recommended that we added it to our style guide. The entry said we would update it when the research was done.

Jokes

You can use the odd joke, if the tone allows. Depending on the context, this can keep things light.

Share the style guide

Organising a show and tell can demonstrate the problems the style guide aims to solve. Make it open to everyone across your organisation. Show everyone that feedback is not only welcome but essential to keep the style guide relevant.

You could also share:

  • a bold all-company email,
  • a subtle link in your Teams profile or Outlook footer,
  • a post on an internal blog.

If you have events where everyone from your organisation is there, that could be another chance to shout about it. 

And you don’t have to wait until it’s published. Talking about your plans and how you're developing the style guide will include your colleagues. Giles Turnbull encourages this as part of what he calls  ‘agile comms’.

Make it accessible 

A ‘well-loved and well-used’ style guide must be accessible to everyone in your organisation. Not a dusty Word doc that lives on 1 person’s desktop. The best way to do this is by publishing it on a platform that:

  • is already well-used, 
  • you can edit,
  • has some nice usability stats on visitor numbers. 

I’ve used Confluence, Teams and MS Sharepoint before. You can use jump links so that you can get the letter you’re after.  And simple plain text works perfectly.

Once your style guide is up and being used, you may feel a bit relieved. But you should also have peace of mind that it will give the people you work with the answers that they need. Entries will come and go, be changed and contested. But a frequently updated style guide is a good sign that lots of people in your company care about being clear and consistent.

Sign up to our newsletter

Get content design insights sent straight to your inbox.




  • Choose what information you get: (required)