Asking for names
Only ask for someone's name if it's essential: design with purpose.
If it is, and you can justify the reason you're asking:
- ask for a ‘Full name’ in one field
- make no assumptions about how the user wants to be addressed — ask them
- make it explicit whose name we’re asking for — include who the other person is if you’re capturing multiple names in one form, for example, ‘Your child’s full name’
- give an accurate instruction if the name needs to be written as it appears on another document, for example, ‘Copy the name from your passport’
If you you have to capture name in separate fields, perhaps because of a legacy system, use:
- ‘First name or names’, ‘Middle name’ (if necessary) and ‘Last name’
- a free text box if you have to ask for title
Frequently asked questions (FAQs)
Do not use FAQs.
Instead, if you know that you are answering a genuine frequently asked question, restructure your content so that the answers form part of the main user journey. And put the information in a logical place in that journey.
We do not use FAQs because:
- users do not know if their question has been frequently asked
- they're often made up by the business rather than genuinely asked by the public
- users have to navigate through irrelevant content to see if their question is there — it’s frustrating and wastes their time
- we should be creating services that speak for themselves: we design with purpose
For more information read Content Strategist Sarah Richards' blog on FAQs.
Hyphens and dashes
What you’re writing will determine where and when you should use hyphens and dashes.
Hyphens (the character you get when you type ‘-’ ) should be used to link words or part of words — they show the user that there’s a connection between them, for example, ‘mother-in-law’, ‘fine-tuned’, ‘Co-op’.
En dashes (
–) should be used for connecting things that are related to each other by distance such as June–July.
Em dashes (
—) can be used in pairs like parenthesis — that is, to enclose a word, or a phrase — or they can be used alone to detach one end of a sentence from the main body.
- use a lead-in line
- make sense running on from the lead-in line
- use lower case at the start of the bullet
- have only one sentence per bullet point — use commas, dashes or semicolons to expand on an item
Bullets should not:
- be paragraphs masquerading as a list for a visual effect
- use a full stop after the last bullet point
- include ‘or’ or an ‘and’ after the bullets
The meeting agenda will be:
- an overview of the last month
- a presentation
- a special announcement
Use a numbered list for a logical sequence of things, like a series of tasks that must be done in a certain order. They do not need a lead-in line and should be complete sentences that start with a capital letter and end with a full stop.
How to put your shoes on:
- Put on socks.
- Put on shoes.
- Tie laces.
Numbers and units
Use ‘one’ unless you’re talking about a step, a point in a list or another situation where using the numeral makes more sense.
Write all numbers in numerals (including 2 to 9) except where it’s part of a common expression and it would look strange, like ‘one or two of them’.
If a number starts a sentence, write it out in full (‘Thirty-four hula-hoops found in researcher’s filing cupboard’) except where it starts a title or subheading.
For numerals over 999, insert a comma for clarity. For example, ‘It was over 1,000’.
Spell out common fractions, such as one-half.
Use a % sign for percentages: 50%, not ‘pc’ or ‘percent’.
Use a 0 where there’s no digit before the decimal point.
In tables, use numerals throughout (not written numbers).
For big numbers use ‘million’, ‘billion’ and so on, written without a space after the number — for example, £3.5million.
Ordinal numbers: first, second as so on
Spell out 'first' to 'ninth'. After that use 10th, 11th and so on.
But, write dates as 10 January 2017.
Use MB not KB for anything over 1MB, for example 4.09MB not 4096KB.
For anything under 1MB, use KB, for example, 569KB not 0.55MB.
Keep units as accurate as possible and up to 2 decimal places. For example, 4.03MB.
- be sentence case
- be less than 65 characters within HTML document
<titles>— Google cuts them off after this
- be unique, clear and descriptive — no puns or single topic words
- be front-loaded with key words if possible — people tend to scan the first couple of words only
- use words you know your users actually search for
- be active where possible, ‘Apply for…’, ‘Report…’, ‘Find…’
- not use acronyms unless they are well-known, like EU, BBC
Validation messages must:
- be flagged at the top of the screen and at each relevant field
- be a bulleted list if there’s more than one error
- be a complete sentence if there’s only one error (no bullet)
- be linked from the top of the page to take users to the relevant field
- help the user fix the problem, for example, ‘Check you've entered the correct sort code — it’s the 6 digit number usually found on your bank card’