伊人直播

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.

Don鈥檛 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 won鈥檛 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 doesn鈥檛 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, don鈥檛 say 鈥榊ou have entered the wrong password鈥�. Say 鈥榃rong password鈥�.

You don鈥檛 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 don鈥檛 notice your copy, you鈥檙e probably doing it right. .

Don鈥檛 exclude anyone

Don鈥檛 rely on shape, size, colour or location alone to communicate information, because not all users will share that frame of reference. For example, don鈥檛 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 shouldn鈥檛 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 doesn鈥檛 know their number, they can click a link labelled 鈥業 don鈥檛 know my National Insurance number鈥�.

Use 鈥榯hey鈥� instead of 鈥榟e or she鈥� or 鈥榟e/she鈥�. It鈥檚 simpler, and works better for people who don鈥檛 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

Don鈥檛 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. Don鈥檛 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.

Don鈥檛 include personal information (like a user鈥檚 name or date of birth) in the <title> field of a URL - you don鈥檛 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.

Further reading

Read these blogs to find out more about writing for user interfaces: