Writing for GOV.UK

How to write well for your audience, including specialists.

Writing well for the web

Research from the Nielsen Norman Group shows people read differently on the web than they do on paper. This means that the best approach when writing for the web is different from writing for print.

Our guidance on writing for GOV.UK is based on research into how people read online and how people use GOV.UK. It explains what each rule is based on.

When you write for GOV.UK you should:

Meet the user need

Do not publish everything you can online. Publish only what someone needs to know so they can complete their task. Nothing more.

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?

Meeting that need means being:

  • specific
  • informative
  • clear and to the point

Finding information on the web

An individual’s process of finding and absorbing information on the web should follow these steps.

  1. I have a question

  2. I can find the page with the answer easily – I can see it’s the right page from the search results listing

  3. I have understood the information

  4. I have my answer

  5. I trust the information

  6. I know what to do next/my fears are allayed/I do not need anything else

A website only works if people can find what they need quickly, complete their task and leave without having to think about it too much.

Good content is easy to read

Good online content is easy to read and understand.

It uses:

  • short sentences
  • sub-headed sections
  • simple vocabulary

This helps people find what they need quickly and absorb it effortlessly.

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.

Writing well for specialists

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.

For example, research into use of specialist legal language in legal documents found:

  • 80% of people preferred sentences written in clear English - and the more complex the issue, the greater that preference (for example, 97% preferred ‘among other things’ over the Latin ‘inter alia’)
  • the more educated the person and the more specialist their knowledge, the greater their preference for plain English

People understand complex specialist language, but do not want to read it if there’s an alternative. This is because people with the highest literacy levels and the greatest expertise tend to have the most to read.

Technical terms

Where you need to use technical terms, you can. They’re not jargon. You just need to explain what they mean the first time you use them.

Legal content can still be written in plain English. It’s important that users understand content and that we present complicated information simply.

If you have to publish legal jargon, it will be a publication so you’ll be writing a plain English summary.

Where evidence shows there’s a clear user need for including a legal term, for example ‘bona vacantia’, always explain it in plain English.

If you’re talking about a legal requirement, use ‘must’. For example, ‘your employer must pay you the National Minimum Wage (NMW)’.

If you feel that ‘must’ does not have enough emphasis, then use ‘legal requirement’, ‘legally entitled’ and so on. For example: ‘Once your child is registered at school, you’re legally responsible for making sure they attend regularly’.

When deciding whether to use ‘must’ or ‘legally entitled’, consider how important it is for us to talk about the legal aspect, as well as the overall tone of voice.

If a requirement is legal, but administrative, or part of a process that will not have criminal repercussions, then use: ‘need to’. For example: ‘You will need to provide copies of your marriage certificate’.

This may be a legal requirement, but not completing it would just stop the person from moving on to the next stage of a process, rather than committing a more serious offence.

Do not use footnotes on documents. They’re designed for reference in print, not web pages. Always consider the user need first. If the information in the footnotes is important, include it in the body text. If it’s not, leave it out.

Know your audience

Your writing will be most effective if you understand who you’re writing for.

To understand your audience you should know:

  • how they behave, what they’re interested in or worried about - so your writing will catch their attention and answer their questions
  • their vocabulary - so that you can use the same terms and phrases they’ll use to search for content

When you have more than one audience, make your writing as easy to read as possible so it’s accessible to everyone.

The GOV.UK audience

The GOV.UK audience is potentially anyone living in the UK, British citizens living abroad or people abroad who want to do business in or travel to the UK. This means government must communicate in a way that most people understand.

The best way to do this is by using common words and working with natural reading behaviour.

If you’re writing for a specialist audience, you still need to make sure everyone can understand what the content is about.

How people read

Knowing how people read means you’ll write in a way they can understand easily and quickly - so you do not waste their time.

All of this guidance is based on the learning skills of an average person in the UK, who speaks English as their first language. This guidance also applies when you’re writing for specialists.

Common words

By the time a child is 5 or 6 years old, they’ll use 2,500 to 5,000 common words. Adults still find these words easier to recognise and understand than words they’ve learned since.

By age 9, you’re building up your ‘common words’ vocabulary. Your primary set is around 5,000 words; your secondary set is around 10,000 words. You use these words every day.

Use short words instead of long words

When you use a longer word (8 or 9 letters), users are more likely to skip shorter words (3, 4 or 5 letters) that follow it. So if you use longer, more complicated words, readers will skip more. Keep it simple.

For example:

“The recently implemented categorical standardisation procedure on waste oil should not be applied before 1 January 2015.”

The ‘not’ is far more obvious in this:

“Do not use the new waste oil standards before 1 January 2015.”

Reading skills

Children quickly learn to read common words (the 5,000 words they use most). They then stop reading these words and start recognising their shape. This allows people to read much faster. Children already read like this by the time they’re 9 years old.

People also do not read one word at a time. They bounce around - especially online. They anticipate words and fill them in.

Your brain can drop up to 30% of the text and still understand. Your vocabulary will grow but this reading skill stays with you as an adult. You do not need to read every word to understand what is written.

This is why we tell people to write on GOV.UK for a 9 year old reading age.

Explaining the unusual

We explain all unusual terms on GOV.UK. This is because you can understand 6-letter words as easily as 2-letter words – if they’re in context. If the context is right, you can read a short word faster than a single letter.

By giving full information and using common words, we’re helping people speed up their reading and understand information in the fastest possible way.

Short sentences

People with some learning disabilities read letter for letter - they do not bounce around like other users. They also cannot fully understand a sentence if it’s too long.

People with moderate learning disabilities can understand sentences of 5 to 8 words without difficulty. By using common words we can help all users understand sentences of around 25 words.

Capital letters are harder to read

When you learn to read, you start with a mix of upper and lower case but you do not start understanding uppercase until you’re around 6 years old.

At first, you may sound out letters, merge sounds, merge letters and so learn the word.

Then you stop reading it.

At that point, you recognise the shape of the word. This speeds up comprehension and speed of reading.

As writers, we do not want people to read. We want people to recognise the ‘shape’ of the word and understand. It’s a lot faster.

Capital letters are reputed to be 13 to 18% harder for users to read. So we try to avoid them.

Block capitals indicate shouting in common online usage. We are government. We should not be shouting.

Ampersands can be hard to understand

Ampersands are allowed in logos – the pictorial logo at the top of an organisation page – but not in body copy.

The reason is that ‘and’ is easier to read and easier to skim. Some people with lower literacy levels also find ampersands harder to understand. As government, we cannot exclude users in any way.

How users read web pages

Users read very differently online than on paper. They do not necessarily read top to bottom or even from word to word.

Instead, users only read about 20 to 28% of a web page according to research from the Nielsen Norman Group. Where users just want to complete their task as quickly as possible, they skim even more out of impatience.

Web-user eye-tracking studies show that people tend to ‘read’ a webpage in an ‘F’ shape pattern. They look across the top, then down the side, reading further across when they find what they need.

What this means is: put the most important information first. So we talk a lot about ‘front-loading’ subheadings, titles and bullet points.

For example, say ‘Canteen menu’, not ‘What’s on the menu at the canteen today?’

Good example

At the activity centre you can:

  • swim
  • play
  • run

Bad example

At the activity centre:

  • you can swim
  • you can play
  • you can run

Titles

Most people who use GOV.UK start with a search engine. Use the same vocabulary as your audience so they can find your content. This begins with your page title and summary.

If people cannot find your page or understand the content, they will not be able to act on it or know it’s for them.

Make your title unique

Titles on GOV.UK must be unique and informative so that users know which page they are on.

Duplicate titles can confuse users - for example if they have more than one page open. This is particularly true for those with visual, cognitive or mobility impairments.

If you use the same title as another page on GOV.UK, you may be breaking the law.

In Whitehall Publisher, a message appears at the top of your content after you save it if the title is already being used: ‘This title is already used on GOV.UK. Please create a unique title’.

In Content Publisher, you should check whether the title is already in use before you publish your content for the first time. You can tell if this is the case by checking if the url it creates has a number at the end (for example ‘/news-story-1’).

In Manuals Publisher, you will not get a warning that the title is already being used. You’ll need to search for the title you want to use to check it’s not already in use.

Check your title makes sense

Your title should make sense:

  • by itself – for example ‘Regulations’ does not say much, but ‘Regulations for environmental waste’ does
  • in search results
  • in document collections

Titles do not have to reflect the official publication title. Make them user focused, clear and descriptive so that users can distinguish if it’s the right content for them.

Find out what the public calls your content by using search tools to look up keywords. Your scheme, organisation or process’s official or internal name may not be what the public calls it.

  1. Check searches on GOV.UK for any related content. This can tell you what people are struggling to find.
  2. Once you know the most popular keywords you can prioritise them in the title, summary, introduction and subheadings

Example

Good title example: Bereavement Allowance (previously widow’s pension)

Good summary example: Bereavement Allowance (previously widow’s pension) is a weekly benefit for widows, widowers or surviving civil partners - rates, eligibility, claim form.

Keep your title short, where possible

Your title should be 65 characters or less (including spaces).

You can use more than 65 characters if it’s essential for making the title clear or unique, but do not do this routinely because:

  • Google cuts off the rest of the title at around 65 characters
  • longer titles are harder to understand

Make your titles clear and descriptive

The title should provide full context so that users can easily see if they’ve found what they’re looking for.

By being general about a topic, you leave the user asking ‘what is this in relation to?’

Example

Bad title example: Hazardous waste - new process

Give the user context around the topic and what this content will tell them:

Good title example: How to dispose of hazardous waste in your area

Avoid saying the same thing twice (tautologies)

Repeating yourself in the title uses up valuable characters that could be used to give more information.

Example

Bad title example: Using and submitting your business expenses

Good title example: Submitting your business expenses

Using ‘ing’ in titles

Use the active verb (‘Submit’) if you use the page to do the thing.

Good form title example: Submit your business expenses

Use the present participle (‘Submitting’) if the page is about doing the thing, but you do it elsewhere.

Good guidance title example: Submitting your business expenses

Do not include the format type in the title

Do not include the name of the format type, such as ‘guidance’ or ‘consultation’, because it appears automatically at the top of a publication. This will free up space to tell the user what the content is about.

Example

Bad title example: Consultation on furniture fire safety regulations

It’s better to use the title to explain exactly what the consultation is for.

Good title example: Amendments to furniture fire safety regulations

Bad title example: Potato guidance

It’s better to explain what the document is about, not its format:

Good title example: How to grow potatoes

Some content types have a specific style, such as:

Remove the date unless it makes the title unique

Put the date in the title if the page is part of a series that has the same title.

For example, a list of annual reports:

Title: Government annual report 2020
Title: Government annual report 2019
Title: Government annual report 2018

It’s helpful to include the date range if you publish multiple versions of the same information for different periods of time.

Do not include your department name unless it makes the title unique

Only add your department or agency name to the title if the content is about your department – for example annual reports or corporate information.

Example

Title example: Highways Agency environmental strategy

On its own, ‘Environmental strategy’ could apply to any department or agency. In this case, it’s better to add the department name to differentiate it.

Summaries

Along with the title, the summary is usually what users see in search results so it should give them a clear indication of what the content is about. Make sure people can see quickly whether the page will have the information they need.

Keep all summaries to 160 characters (including spaces) as Google usually only shows the first 160 characters in search results. If your summary is longer, make sure you cover the main point of the page in the first 160 characters.

Summaries should end with a full stop. It can help people who use assistive technology like screen readers.

Use plain English to avoid confusion

Use plain English to make the purpose of the content clearer, and write like you’re talking to your user one-on-one.

Bad summary example: Implementing the government’s strengthened approach to budget support: technical note

Good summary example: How the government is making budget support more effective in countries supported by the UK

For more examples of words not to use in summaries, read the words to avoid list.

Avoid redundant introductory words

Do not repeat the content type in the summary - for example, do not say “this consultation is about…” or “a form to…”.

Use as few words from the title as possible, and include keywords that you’ve not used in the title.

Use active language

Keep summaries active and include a verb. You can use words like ‘How…’, ‘What…’ and ‘When…’ to introduce active words, for example ‘When applying for a…’.

Structuring your content

Page length

There is no minimum or maximum page length for GOV.UK. However:

This means that the quicker you get to the point, the greater the chance your target audience will see the information you want them to.

It’s most important that you write well. If you write only a single paragraph but it’s full of caveats, jargon and things users do not need to know (but you want to say) then it’s still too much.

Writing body copy

Keep your body copy as focused as possible.

Remember that you’re likely to be battling outside factors for people’s attention, not least their mood and situation. They might be looking on a mobile on a train, trying to complete their task online in the middle of a stressful family event or any combination of multiple unknowns. If you want their attention, do not waste their time.

  1. Do not repeat the summary in the first paragraph.
  2. Use the ‘inverted pyramid’ approach with the most important information at the top tapering down to lesser detail.
  3. Break up text with descriptive subheadings. The text should still make sense with the subheadings removed.
  4. Paragraphs should have no more than 5 sentences each.
  5. Includes keywords to boost natural search rankings.

Headings

Use heading levels (subheadings) to break up your content and give it a sensible navigation structure. Each page title is an H1 (heading level 1), so start at H2 and do not use H1 in your content.

Do not skip heading levels when moving from a higher level to a lower level, for example from H2 to H4. Screen reader users may navigate using a list of headings - a missed heading level can make this confusing.

Do not use bold text instead of using subheadings. This is inaccessible because a screen reader will not recognise it as a header.

You do not always need to have text between headings. Missing text between headings is not a Web Content Accessibility Guidance (WCAG) fail, but sometimes adding text between headings is helpful to provide context.

For example, users expect to go from H1, normally the page title, to H2 without any explanatory text.

It’s usually helpful to have content between an H2 and H3 especially when it’s not clear how the H3(s) follow from H2.

When you link to a service, make sure the start button is under a heading which relates to the start button’s task (for example, ‘Register online’). Otherwise it will not be accessible.

You do not always need text between the heading and the start button. View a good example of a start button directly under a heading.

Make sure your subheadings are front-loaded with search terms and make them active.

Make sure start buttons are under a related heading. If the start button is nested under a heading, that heading must relate to the start button’s task (for example, ‘Register online’). Otherwise it will not be accessible.

Do not use:

  • questions - they’re hard to front-load (putting the most important information first) and users want answers, not questions
  • technical terms unless you’ve already explained them
  • ‘introduction’ as your first section – users do not want an introduction, just give the most important information

Watch this Why you should use the correct heading structure in your content video which shows how a screen reader interacts with headings. If you can’t see the video, you can read the full transcript in the description section.

Do not use FAQs

FAQs are strongly discouraged on GOV.UK. If you write content by starting with user needs, you will not need to use FAQs.

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

If your call-centres get questions that really are frequently asked, get in touch and GDS will help find a way to take care of those user needs.

Writing to GOV.UK style

It’s important to stick to the style guide. The style guide is based on a lot of user testing.

GDS commissioned research on the impact of style guides. Have a look.

Be concise

To keep content understandable, concise and relevant, it should be:

  • specific
  • informative
  • clear and concise
  • brisk but not terse
  • incisive (friendliness can lead to a lack of precision and unnecessary words) – but remain human (not a faceless machine)
  • serious but not pompous
  • emotionless – adjectives can be subjective and make the text sound more emotive and like spin

You should:

  • use contractions like you’ll (but avoid negative contractions like can’t)
  • not let caveats dictate unwieldy grammar – for example say ‘You can’ rather than ‘You may be able to’
  • use the language people are using – use Google Trends to check for terms people search for
  • not use long sentences – check any sentences with more than 25 words to see if you can split them to make them clearer

(Note: words ending in ‘–ion’ and ‘–ment’ tend to make sentences longer and more complicated than they need to be.)

Active voice

Use the active rather than passive voice. This will help us write concise, clear content.

Addressing the user

Address the user as ‘you’ where possible. Content on the site often makes a direct appeal to citizens and businesses to get involved or take action, for example ‘You can contact HMRC by phone and email’ or ‘Pay your car tax’.

Capitalisation

DO NOT USE BLOCK CAPITALS FOR LARGE AMOUNTS OF TEXT. IT’S HARD TO READ.

Date ranges

Use ‘to’ instead of a dash or slash in date ranges. ‘To’ is quicker to read than a dash, and it’s easier for screen readers.

Always explain what your date range represents, for example ‘tax year 2019 to 2020’ or ‘September 2019 to July 2020’. Date ranges can be the academic year, calendar year or tax year. This is why date ranges must be very, very clear.

If you’re comparing statistics from 2 different tax or financial years, use ‘Comparing the financial year ending 2018 with that ending 2019, there was a 9% decrease’.

Gender-neutral text

Make sure text is gender neutral wherever possible. Use ‘them’, ‘their’, ‘they’ etc.

How to add links to content and GOV.UK’s linking policy

Plain English

Plain English is mandatory for all of GOV.UK. One of the parts most people pick up on is the plain English (or words to avoid) list.

This is not just a list of words to avoid. Plain English is the whole ethos of GOV.UK: it’s a way of writing.

The list is not exhaustive. It’s an indicator to show you the sort of language that confuses users.

Do not use formal or long words when easy or short ones will do. Use ‘buy’ instead of ‘purchase’, ‘help’ instead of ‘assist’, and ‘about’ instead of ‘approximately’.

We also lose trust from people if we write government ‘buzzwords’ and jargon. Often, these words are too general and vague and can lead to misinterpretation or empty, meaningless text. We can do without these words.

With all of these words you can generally get rid of them by breaking the term into what you’re actually doing. Be open and specific.

Write conversationally – picture your audience and write as if you were talking to them one-to-one but with the authority of someone who can actively help.

Using ‘please’

There’s usually no need to say ‘please’ or ‘please note’. This includes when giving an instruction or explaining what a user needs to do (for example, please contact us).

Writing about disability

Words to use and avoid when writing about disability.

When to use ‘we’

In the ‘about us’ section of the organisation page, lead with ‘we’ – it will be very obvious who the ‘we’ is on this page.

In policies, ‘we’ is also used, for example, ‘We announced our intention to do x as part of the coalition agreement.’

However, it’s not obvious who ‘we’ is in all content. For example, in a publication or detailed guide, users might enter the content in the middle of a page. They could arrive at an H2 heading from the navigation bar on the side, or skim read from the top until they find the section they want.

Each time you use ‘we’, make sure you’ve already used the full name of the department or agency in that specific section. Do not assume the audience will know who the ‘we’ is.

Offensive language

You must not use offensive words or terms in GOV.UK content, including attachments.

This includes using swear words and words in an offensive context about:

  • race
  • ethnicity
  • nationality
  • religion
  • disability
  • mental health
  • gender identity
  • sexual orientation
  • body parts
  • sexual references

Tribunal decisions published by HM Courts and Tribunals Service are exempt. This is because decisions include quotes from people involved in a case.

Read more about:

After publication

Check your content is working for your users

Confirm regularly that your content works for your users. Use Content Data to check:

  • the number of searches from the page (a high number may be an indication people did not find what they were looking for)
  • the amount of user feedback left on GOV.UK
  • the proportion of users who found the page useful

It’s also worth checking:

  • Google Analytics to see how users got to your page and where they clicked next (check if they’re going where you expected or wanted them to)
  • feedback from any offline channels, for example helplines

Change notes

When you add, change or remove information on some pages you’ll need to write a change note, unless it’s a minor edit like a typo or style change.

Examples of formats that need change notes for updates include publications, detailed guides, document collections, news stories and press releases.

Who can see change notes

Change notes are public. They are emailed to subscribers and for some content types they are published along with the time and date on the page where the change is made. This helps the government be transparent about any changes made to public information.

The text of each change note is emailed to users who have signed up for email alerts about changes to a page or any taxonomy topics the page is tagged to.

For example, if you sign up for email alerts on the education taxonomy topic you’ll be emailed when any of the related pages are updated. 

This means change notes need to be:

  • very clear about what has changed and where the change appears on the page
  • used carefully so users are not being sent emails about changes that are irrelevant to them

You can sign up to an email alert to get an idea of what they look like when a user gets them.

When to write a change note

You do not need to write a change note for the following types of changes:

  • fixing typos

  • style changes like changing a heading or layout

  • adding or removing broken links (unless they are links to something that is crucial to the task or knowledge that users need)


You should write a change note when:

  • adding new information that means a user has to do something differently or know something new
  • removing guidance that is out of date or misleading
  • updating changes to fees or deadlines


How to write a change note

Before you write a change note make sure that you:

  • understand what has changed and how this is important for the user
  • get any policy or comms input needed to make sure you’re able to clearly explain what has changed and any potential impact for the user

Include the changed information in the change note itself if possible so users can see what has changed without having to go to the page itself. 

If a lot of content is being changed at once, write a summary of what has changed and where (for example, page number, chapter or section). Apply the same principles if you are adding or updating attachments. 

Change notes should follow the style guide and content design principles:

  • be as specific as possible
  • write in full sentences
  • include the most important information about what has changed first

Do not say the page has been updated without saying what has changed.

Good examples

Potatoes are now on the banned vegetable import list from outside the EU.

Edited chapter 6 - centres in Cardiff and Aberystwyth have closed. There’s only one service centre now, in Merthyr Tydfil.

Form A123 - question 4 on page 2 now asks for your previous address.

New guidance on school meal procedures that apply from 1 March 2019 added to the ‘Meal planning for primary schools’ section.

Bad examples

Guidance updated.

Updated the collection page to inform users of the name of the publication.

Updated to add social media graphics for Twitter and Facebook.

Removed broken link.