Content design patterns

Natalie Shaw
5 min readJan 26, 2016

--

Taken from the Government Digital Service’s design principles

In software engineering, design patterns and repositories are pretty commonplace. In content design and content strategy, it’s not really the case. Style guides are prescriptive rather than reactive, most of the time.

I’m a stickler for consistency and speeding things up in big teams of content people, so I’ve found myself setting up a content design pattern repository for my last 3 clients (GDS, HMRC and Citizens Advice).

According to Google, ‘content design patterns’ aren’t a thing at the minute — so the least thing I can do is blog about it.

Recurring problems

As part of my day to day, I look at other people’s content. I also spend some of the day writing my own stuff. Even with the best style guide by a team’s side, people tend to divert and come up with their own patterns. They may not even realise they’re doing it.

On the flip-side, consistency is really important to users. If a user’s navigating through multiple pieces of content (or even multiple screens within a transaction), it’s easier for them to complete tasks if we:

  • refer to the same things using the same words
  • use the same type of patterns with language
  • write and design naturally and consistently

This goes beyond the realms of the traditional style guide. It’s less about tone and individual words, and more about design and user journeys.

When I was working at GDS on GOV.UK, I developed and maintained a content design patterns repository for a team of around 50 content designers. It went on to become a crucial resource. I’ve just started on a repository for Citizens Advice — the gap cried out to me as the team expanded.

The idea’s this: when someone struggles for a few seconds over a phrase (or anything), it’s only natural to assume that someone else has been in this predicament before. That’s where the repository comes in – it throws up a solution (designed by consensus), and people never have to suffer alone again.

Time for some examples.

If you’re using phrases repeatedly

I started the repository by pulling out clear and easy phrases like:

  • “download and fill in the form” (for any form)
  • “you must enter a <field name>” (for error messages in interactive content)
  • “open Monday to Friday, 9am to 5:30pm” (for helplines)

It’s going to take a hardy sub-editor (or ‘2i’) to pull these things out as they’re often subtle and not the main focus of a piece of content. But it’ll sure help them later down the line when they’re stacked with a deadline and a ton of proofing to do.

Patterns and sentence structure

Over the years, I’ve seen users struggle with sentences startingwith “if”. It seems to create worry unnecessarily, so again it was time for a pattern:

“Try to write without ‘if’ at the front. It’s ok if you’re defining a small edge case.”

Information hierarchy

I’ve made a start on conventions for hierarchy. The first pattern I’ve introduced is for ordering rows in tables:

“Lead with the common case and go from there. Or go alphabetically, if it’s not obvious or they’re evenly spread.”

This one neatly applies to other things too — like the ordering of radio buttons in questions.

A little bit of consistency really goes a long way, but it’s only really obvious if you write it down and make it public.

Using design elements consistently

Our pattern for GOV.UK’s callouts was:

“Warning callouts: Are you about to die? Or be arrested? Or pay a massive fine? Use them sparingly.

Information callouts: question every callout, and remember they break the flow. Don’t use callout after callout. Be aware that users sometimes skip over them.”

I’ve found that content people tend to love callouts — anything to spice up a piece of content. Rather than keeping them locked up for a special occasion, content design patterns made it much clearer when they should be used.

Since writing that pattern, I’ve watching loads of usability testing in which people have missed content that’s positioned between 2 prominent design elements. So even more reason for it.

Grammar

Confession: I can’t tell the difference between a split infinitive and a past participle. I’m from the school of “if it reads well, then great”, in fact.

But that said, it’s important to be consistent with things like scare quotes. So I introduced a pattern at Citizens Advice:

“Only use scare quotes if the word or phrase is really weird (and you want to distance yourself from it). Be wary of scare quotes making things sound fake.”

Hopefully the commonality is starting to emerge with these example patterns – they’re all pretty damn logical…

When Google Trends confuses you (a niche use of a pattern)

Another:

“If you desperately want to use plain English but people still use the jargon because they’ve been so exposed to it, it’s a good idea to reflect this:

  • for SEO
  • to make sure it’s not new when the user has to encounter it on a form (if they have to)

Don’t use it every time though. Find the best way to include the jargon without breaking the flow of the sentence. It depends on how long the sentence is, most of the time.”

Here’s a good example:

“… you’ve asked to settle before the case came to court (sometimes called a ‘defence of tender before claim’)”

Maintaining a pattern repository

It’s really important that the repository gets well looked after. The team will inevitably want more patterns once it gets going, and you may even find that research shows you got something wrong once (and that’s fine).

It’s also a good chance for an open conversation about style and conventions. And a nice chance to show just how content design goes way beyond the words.

If you’re working across multiple locations, products, subject areas and media, you’ll probably find it invaluable. It’ll help you take a step back from your work, too.

If you want to know more

Tweet me. I’m obsessed with this kind of thing and will happily tell you more.

--

--

Natalie Shaw

Freelance service and content design principal. Ex-Meta, GDS, Citizens Advice. Trust and safety specialist.