Writing for user interfaces

Be as clear and concise as possible and use the same language as your users. This helps:

• reduce the amount of time you spend dealing with mistakes
• make your service inclusive for people who struggle with reading or have limited English
• make your service accessible

It’s especially important to choose an intuitive name for your service. If your title reflects your users’ language, they’ll be able to find your service and understand what it does.

Ignore strict grammar conventions if it makes things clearer.

On the internet people tend to scan rather than read. Even more so when they’re using a transactional service.

So start with less. If you’re creating a form, start with some simple questions and only add help text if user research shows that you need it.

Design your service or tool to take account of the fact that lots of people will not read the content in detail. For example, ask questions to establish eligibility rather than putting a long list of eligibility conditions on the start page.

If you find yourself having to explain how the user interface works, that’s a sign something has gone wrong. Fix the interface so it doesn’t need explaining.

Break up copy into short sentences. One idea per sentence. Put the important words first and drop any unnecessary words.

For example, if you’re writing help text there’s usually no need to say ‘This is the total cost’. Just say ‘Total cost’. If you’re writing an error message, do not say ‘You have entered the wrong password’. Say ‘Wrong password’.

You do not usually need the word ‘now’. For example, just say ‘apply’ rather than ‘apply now’ (unless you’re giving the user two options: apply now or apply later).

Be approachable and helpful, but not overly familiar. Remember that it’s government ‘speaking’.

Say ‘sorry’ if something serious has gone wrong, for example, the service has stopped working completely. ‘Sorry, there is a technical problem. Please try again in a few moments.’

There’s no need to say ‘sorry’ in validation error messages.

There’s usually no need to say ‘please’ or ‘please note’.

There’s usually no need to say thank you. For example, it’s fine to say ‘Application complete’ rather than ‘Thank you for your application’.

Avoid things like humorous error messages. People often use government services for serious things or when under stress.

If people do not notice your copy, you’re probably doing it right. 

Shape, size, colour or location should not be used alone to communicate information, because not all users will share that frame of reference. Examples include:

• ‘click the green button’
• ‘use the menu on the left of the page’
• ‘find more information in the square box’

Use ‘select’ rather than ‘click’ as not all users use a clickable mouse.

Break up long pages with headings. It’s easier to scan and read. Headings should describe the purpose of the text that follows, they shouldn’t be part of the text.

Screen reader users often read out lists of links in isolation, so make the purpose of the link clear from the link text alone. For example, ‘click here’ is not accessible link text.

Sometimes you need to shorten link text to avoid lots of duplication. If you do that, make sure links are still accessible to screen readers.

Follow the GOV.WALES style guide on how to write times and dates, spelling, punctuation, acronyms and other conventions.

Headings and <title>

It’s fine to have headings as questions. In fact, it can help to remove duplication.

But make sure every text box, set of radio buttons or other input field still has a question directly associated with it in the html, so it makes sense to screen readers. For example, by using a visually hidden <legend> or <label>.

Each page should have a single <h1>. The <h1> should describe what the page does.

The <title> should be based on the <h1>, and follow this format:

Find out how your Welsh rates of income tax is spent in Wales | GOV.WALES

Pronouns (we, you, me, my)

Forms are like a conversation between the service and the user.

If it’s the service ‘speaking’, the user is ‘you’ or ‘your’ and the service is ‘we’, ‘us’, ‘our’ and so on.

If it’s the user ‘speaking’, use ‘I’, ‘me’ or ‘my’.

This applies to all microcopy, including headings, input labels and link text.

Use ‘they’ instead of ‘he or she’ or ‘he/she’. It’s simpler, and works better for people who do not identify as male or female.

Capitalisation and punctuation

Use sentence case everywhere, except for proper nouns.

Headings and input field labels are sentence case, but not punctuated. Write other copy in full sentences, with a full stop at the end.

Contractions, abbreviations and acronyms

Use non-negative contractions, for example 'they've', 'we'll'. Avoid using 'should've', 'could've', 'would've' as these are hard to read.

Do not use negative contractions, for example don't and can't. Strong evidence shows users misread these and risk making the wrong decisions.

The first time you use an abbreviation or acronym explain it in full on each page unless it’s well known, like UK, NHS or BBC. This includes government departments or schemes. Then refer to it by initials.

Make sure your URLs are clear and readable. This will help users understand where they are in your service.

Do not include personal information (like a user’s name or date of birth) in the <title> field of a URL, you do not want it to show up in your site analytics.

All language should be as simple to understand as possible, including privacy policies and declarations. Explaining users’ rights and obligations clearly is good legal practice as well as being good for usability.