About the same time I was starting out as a tech writer, I heard of the Government Digital Service for the first time. They were totally overhauling the UK government’s web presence, and they were doing it in the open: sharing what they were trying and what they’d learnt, blogging about their principles. I found their work inspiring - laser-focused on meeting the needs of citizens, on being clear and human-centered.
I was working in a very different domain, but their ideas and processes resonated with me hugely. A lot of the core principles that I work by came from GDS - from their style guides, their service patterns, their blog posts. I come back to the stuff they’ve shared over and over again. It articulates so well the basic principles of technical writing, and somehow cuts through so much nonsense. They have a gift for slogans as well - I wish I knew how to write those.
So I’ve collected a few favourite bits of their work to share here. They’re talking about writing on behalf of government, but I think the ideas apply really to any writing, if you care about it working well for your readers.
On designing content
What is content design - an introduction to the ideas behind designing content rather than writing copy:
Government has a tendency to publish content that is more focused on what it wants to say than what the user needs to know. This makes content difficult to understand and act on.
Do not publish everything you can online. Publish only what someone needs to know so they can complete their task. Nothing more.
On starting with user needs:
People do not usually read text unless they want information. When you write for the web, start with the same question every time: what does the user want to know?
On complex writing:
The main purpose of GOV.UK is to provide information - there’s no excuse for putting unnecessarily complicated writing in the way of people’s understanding.
On plain language:
Government experts often say that because they’re writing technical or complex content for a specialist audience, they do not need to use plain English. This is wrong.
Research shows that higher literacy people prefer plain English because it allows them to understand the information as quickly as possible.
The case against FAQs (emphasis mine):
FAQs are discouraged because they:
- duplicate other content on the site
- cannot be front-loaded (putting the most important words people will search for), which makes usability difficult
- are usually not frequently asked questions by the public, but important information dumped by the content editor
- mean that content is not where people expect to find it; it needs to be in context
- can add to search results with duplicate, competing text
See also FAQs: why we don’t have them.
Planning content - being totally clear about the only things they will publish:
All content published on GOV.UK must have a clear user need backed up with evidence.
Content should be published either:
- as guidance to help users complete a transaction with government
- to help users understand what government is doing
Content that does not do one of these things should not be published on GOV.UK.
On talking about future state:
[our content] only describes future changes if they are certain or very likely to happen and affect choices a user can make right now, for example if users should apply for something now because a scheme is closing or a service will be down for maintenance.
Principles and slogans
A huge strength of GDS is expressing ideas in clear, powerful slogans. I love the Government Design Principles (and the poster versions) - my favourite is Do the hard work to make it simple:
Making something look simple is easy. Making something simple to use is much harder - especially when the underlying systems are complex - but that’s what we should be doing. Don’t take “It’s always been that way” for an answer. It’s usually more and harder work to make things simple, but it’s the right thing to do.
The government design tumblr has some great slogans on posters:
- Don’t ask: how should it look? Ask: what must it do?
- Find what works, not what’s popular
- Good services are verbs, bad services are nouns (Explanatory blog)
- Describe the task, not the technology - I refer to this all the time
- You are NOT your user
- Giving, asking for and receiving feedback
Giles Turnbull on writing
I love the way Giles writes. This stuff isn’t from the GDS blogs, but I think it still fits in here.
Use the words normal people would use:
They could have written anything on those wooden troughs. They could have just put: “NO STANDING”, which would sound aggressive. They could have put “Don’t stand here”, but that would have been unclear – don’t stand where? On the wooden bit? In front of it? People wouldn’t know.
The words they did use were exactly the words a normal person would use to tell their kids (it’s mostly kids) not to stand on the wooden bit. “Please don’t stand on this wooden bit.” It’s simple, it’s clear, and it’s something anyone can understand.
Think about the best presentations and speeches you’ve heard: they weren’t given in a formal tone either. They may have conveyed a very serious message, or covered a very important issue, but the best public speakers can do that with their own voice, and their own personality, showing through. They speak like humans, even though they’re representing organisations.
Good public writing works the same way. Even very large organisations can sound human, and can make themselves easier to understand and relate to, if they abandon the corporate voice and adopt the human voice instead.
Thinking out loud about internal comms:
Say what you mean. Don’t be vague. Don’t expect people to read between the lines. Don’t assume they know as much about a particular situation as you do. Don’t leave any room for ambiguity.
Don’t say you’re a “thought leader” - just show you can think.
Turn question slides into statement slides, and more good advice on doing presentations.
Bits from the blog
A random selection of nice posts:
- “However, there is a limit to content designers' powers: They can’t explain something that didn’t make sense in the first place” - Services that are simple to explain
- “It’s our job as content designers to get out of the way of people completing what they came to do. One of the things we learnt on the citizen beta of GOV.UK is that this is harder than it sounds. A refrain heard daily was ‘do you actually need to know that at this point?'” - If content is king
- “Our editorial principles are built around being informative, succinct, reassuring, brisk (but not terse) and most importantly focusing on what you can usefully tell people they can do. We won’t be giving advice so, for example, we may tell you you can get a divorce by filling in a certain form and going through a certain process - but we won’t be covering how you tell your children” - It’s all about the words
- “Our hope is that no one ever notices the language. We don’t need it to ‘build the GOV.UK brand’ by being obviously quirky or clever and it doesn’t need to feel especially weighty or governmental. It needs to get out of the way and get you where you need to go” - Writing simply
- “By working in the open, anyone can contribute to our documentation, and the whole team has shared ownership of the content. It’s a deliberate departure from a more traditional model where a technical writer might sit in another department writing documentation using a different project management approach to their technical experts.” - Why we use a ‘docs as code’ approach for technical documentation
- Several examples of changing your mind after experimentation and research: Rethinking related links, One thing per page, and Removing the external link icon.
- Editorial review process
- Finding your way around GOV.UK
- “The best interaction and information design is stuff that can be glanced-at.” Clever and useful design patterns
That’s it
That’s probably plenty to be getting on with!