Writing for user interfaces

From:: Design community

Aim to minimise by being as clear as possible and using 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

Even specialist users prefer clear language. No one likes having their time wasted, .

It鈥檚 especially important to choose an intuitive name for your service. If your title reflects your users鈥� language, they鈥檒l be able to find your service and understand what it does.

Do not follow strict grammar conventions if it makes things clearer not to.

Think about alternatives before you add more words

On the internet . Even more so when they鈥檙e using a transactional service.

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

Design your service to take account of the fact that lots of people will not read the content in detail. For example, 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鈥檚 a sign something has gone wrong. Fix the interface so it does not need explaining.

Keep copy short and direct

Break up copy into short sentences. One idea per sentence.

Space is at a premium with user interfaces. So put the important words first and drop any unnecessary words.

For example, if you鈥檙e writing help text there鈥檚 usually no need to say 鈥楾his is the total cost鈥�. Just say 鈥楾otal cost鈥�. If you鈥檙e writing an error message, do not say 鈥榊ou have entered the wrong password鈥�. Say 鈥榃rong password鈥�.

You do not usually need the word 鈥榥ow鈥�. For example, just say 鈥榓pply鈥� rather than 鈥榓pply now鈥� (unless you鈥檙e giving the user two options: apply now or apply later).

Tone

Be approachable and helpful, but not overly familiar. Remember that it鈥檚 government 鈥榮peaking鈥�.

Say 鈥榮orry鈥� if something serious has gone wrong - for example, the service has stopped working completely. 鈥楽orry, there is a technical problem. Please try again in a few moments.鈥�

There鈥檚 no need to say 鈥榮orry鈥� in validation error messages.

There鈥檚 usually no need to say 鈥榩lease鈥� or 鈥榩lease note鈥�.

There鈥檚 usually no need to say thank you. For example, it鈥檚 fine to say 鈥楢pplication complete鈥� rather than 鈥楾hank 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鈥檙e probably doing it right. .

Do not exclude anyone

Do not rely on shape, size, colour or location alone to communicate information, because not all users will share that frame of reference. For example, do not say things like:

鈥榗lick the green button鈥�
鈥榰se the menu on the left of the page鈥�
鈥榝ind more information in the square box鈥�

Break up long pages with headings. It鈥檚 easier to scan and read. Headings should describe the purpose of the text that follows - they should not 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, 鈥榗lick 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. For example, by adding hidden text to the 鈥榗hange鈥� links on check your answers pages.

Style

Follow the 扒哥吃瓜 style guide on how to write times and dates, spelling, punctuation, acronyms and other conventions.

Headings and `<title>`

It鈥檚 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:

Where do you live? - Register to vote - 扒哥吃瓜

Pronouns (we, you, me, my)

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

If it鈥檚 the service 鈥榮peaking鈥�, the user is 鈥榶ou鈥� or 鈥榶our鈥� and the service is 鈥榳e鈥�, 鈥榰s鈥�, 鈥榦ur鈥� and so on.

If it鈥檚 the user 鈥榮peaking鈥�, use 鈥業鈥�, 鈥榤e鈥� or 鈥榤y鈥�.

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

For example, the Register to vote service asks users 鈥榃hat is your National Insurance number?鈥�. If the user does not know it, they can select a link 鈥榝ind your National Insurance number鈥� or select 鈥業 am not sure what a National Insurance number is鈥�.

Use 鈥榯hey鈥� instead of 鈥榟e or she鈥� or 鈥榟e/she鈥�. It鈥檚 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

Do not use 鈥榠e鈥�. Use 鈥榝or example鈥� instead of 鈥榚g鈥�.

Use simple contractions like 鈥榶ou鈥檙e鈥� and 鈥榳e鈥檒l鈥�.

Avoid:

should鈥檝e, could鈥檝e, would鈥檝e, they鈥檝e - these can be hard to read
negative contractions like 鈥榗an鈥檛鈥� and 鈥榙on鈥檛鈥� - some users find them harder to read, or misread them as the opposite of what they say

Include any relevant acronyms on your 扒哥吃瓜 start page for SEO purposes, but try to avoid using them inside the transaction.

And if you do use them, spell them out in full on each page. Do not rely on people remembering them across different pages.

URLs

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鈥檚 name or date of birth) in the <title> field of a URL - you do not want it to show up in your site analytics.

Legal content

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.

扒哥吃瓜