When asking users for their email address, you should:

• make the field long enough
• make it clear why you’re asking
• help users to enter a valid email address

You may also need to check that users have access to the email account they give you.

Make the field long enough

Make sure the field is long enough to accommodate at least 95% of your users’ email addresses.

You can analyse your user data to establish what this is. A good rule of thumb is 30 characters.

Tell users why you want the email address

Make it clear what the email address will be used for so that:

• users feel confident that you’re not going to abuse it
• users with multiple email addresses can choose which one to give you

Help users to enter a valid email address

Help your users to enter a valid email address by:

• checking that what they’ve entered is in the format of an email address allowing users to paste the email address
• using the type=“email” attribute so that devices display the correct keyboard
• play their address back to them so they can check and change it

You can also check for common misspellings of popular email providers (for example ‘homtail.com’ instead of ‘hotmail.com’). Warn users if you detect one, but allow them to proceed in case it’s a genuine email address.

Some services ask users to repeat their email address. This adds work for the user and should not be implemented unless your research has shown it to be effective.

If you have to ask about gender, you should:

• list the fields in alphabetical order: ‘Female’, ‘Male’, ‘Unspecified’
• do research to test that this works for your users

Avoid using pronouns

You should address the user as ‘you’ where possible and avoid using gendered pronouns like ‘he’ and ‘she’.

In some cases you may need to use pronouns, for example if your service allows people to jointly apply for something.

Don’t use titles to guess gender

You shouldn’t guess someone’s gender based on a title because:

• some titles aren’t gendered (for example Dr, Rev, Major)
• titles can be changed by deed poll to one that’s different from a person’s gender or sex

Make sure fields are long enough and support all the characters needed to accommodate 95% of the names you need to capture

Use a single name field where possible

Use a single name field because it can accommodate the broadest range of name types and requires less effort for users to understand.

The problem with multiple name fields

Multiple name fields mean there’s more risk that:

• a person’s name won’t fit the format you’ve chosen
• users will enter their names in the wrong order
• users will try to enter their full name in the first field

Labelling name fields

For single name fields, use ‘Your full name’.

For multiple name fields, use:

• ‘First name’
• ‘Last name’

If you can’t use a single name field and many of your users aren’t from the UK, use these labels:

• ‘Given names’
• ‘Family name’

Don’t use a ‘middle name’ field unless you have to, and make sure it’s optional. You don’t need to mark it as optional.

Make it clear whether you need someone’s common name or their full legal name.

Avoid asking for people’s title

You shouldn’t ask users for their title.

It’s extra work for users and you’re forcing them to potentially reveal their gender and marital status, which they may not want to do.

There are ways to address people in correspondence without using title, for example by using their name.

If you have to use a title field, make it an optional free-text field and not a drop-down list. Predicting the range of titles your users will have is impossible, and you’ll always end up upsetting someone.

Remember to deal with the name data sensibly in any resulting correspondence.

Use a single text field labelled ‘National Insurance number’, like this:

You should also:

• allow for 13 characters - National Insurance numbers are often spaced in pairs
• avoid using ‘NINO’ or ‘NI number’ as the label
• avoid using ‘AB 12 34 56 C’ as an example (it belongs to a real person) - use ‘QQ 12 34 56 C’ instead

First, test your service without any progress indicators. Many services are simple enough that users don’t need them.

Try improving the order, type or number of questions before adding a progress indicator.

If people still have problems then try adding a simple step or question indicator.

This approach is compact and usually enough to give people the confidence to continue.

Only include the total number of questions if you can do so reliably. If the total number changes as the user continues through the service, make sure you update the indicator.