Names

[govuk-design-system]

Use this issue to discuss this pattern in the GOV.UK Design System.

[mikeash82]

@gavinwye commented on 31 Jan 2017

Screenshot

Asking for a name

We also tell people the name we have for them but this is done as part of #4 (HMRC header)

@MarkKeeling commented on 13 Nov 2017

This pattern is ideal for HMRC's needs (due to tech constraints) however wider XGov does consider a single entry more acceptable.

@stevenaproctor commented on 15 Nov 2017

@gavinwye Any idea why the service manual says you do not have to mark a middle name as optional but elements says you do? See https://www.gov.uk/service-manual/design/names#labelling-name-fields and http://govuk-elements.herokuapp.com/form-elements/#form-optional-fields

@russellthorn commented on 17 Nov 2017

Register to vote have this page - https://www.registertovote.service.gov.uk/register-to-vote/name (but have omitted the optional label for the middle name)

@stevenaproctor commented on 17 Nov 2017

@russellthorn The service manual actually says to leave the optional label off middle name. I assume it will be because people without middle names will know to leave it blank. And if you put it on people with middle names may decide to leave it out.Maybe the pattern needs to be "Middle name, if you have one" or not ask for it at all. What happens if someone with a middle name leaves it blank?

@russellthorn commented on 17 Nov 2017

@stevenaproctor I'm not sure what happens if you leave middle name blank, even though I re-registered to vote recently. I think it does nothing?

[edwardhorsford]

I'm seeing an issue with the name pattern.

My service has started launching to real users recently (internal service). We use the user's name in various places in the service - to show who is working on a case and for assigning cases.

I'm seeing quite a few users include their middle name. We don't actually need the middle name - and my hunch is that in most cases they wouldn't otherwise provide it / chose to use it in regular usage - but the field is labelled "Full name" so without other guidance, they're including it.

Thus it feels like the single field biasses towards longer / more names - which might not suit all services and might well not suit how users refer to themselves.

Anyone else come across this?

We could try adding hint text to say that middle name isn't required, or label text like "First and last names".

[torydunn-hmrc]

We regularly have discussions about how suggesting the single "full" name field is not appropriate for gather data to set up an account or user, as the data base will need to be able to separate last name accurately. The single field can certainly work for signing back in, although as Ed points out, the label "full" can be confusing.

[edwardhorsford]

Our service collects a single field "Full name" as per the pattern. In addition to the above issue where some users are giving us a much longer name than we really need, I'm seeing a minority of users only provide their first name.

I speculate this is because they're used to filling their name in two boxes so expect a second box later.

Has anyone else observed this?

[Just-Spirit]

I realize my edge case is hardly unique, but speaking for someone who's name is mononymous (In the whole of human history, not everyone has had a multiple names), the problem that actually arises in splitting name fields is caused by subsequently making 'BOTH' first and last conditional - sometimes to the point of perversity, and also by completely disallowing forward progression/submission (unless both are completed) - this may be brushed away as either a problem (or not a problem) by yourselves but you may be surprised, as it causes a lot of forward ramification, especially with embuggerant people and officialdom, something I am hopeful and thinking that (from this article) the Government is at least trying to distance itself from - examples are the HMPO and DBS (when applying for work) and yes the sign up to vote one, too! 😕 - and what I like to consider my given/first name, though I was disallowed it's use in signing up to GitHub, is just,

Spirit

(A service user)

[EmmaFrith]

Is 'Last name' the most inclusive option? Wondering whether 'Last names' would be more inclusive for people who have 2 surnames - for example, in Spanish naming customs.

[chrisadesign]

For multiple name fields, use:

'First name'
'Last name'

If users are from outside the UK, use the labels:

'Given names'
'Family name'

If the person could be either is the recommendation to use the second option? Could the guidance have some clarity?

[edwardhorsford]

You could use one with the other as a hint? Attached is a screenshot from the Apply for teacher training service:

Note: looking at the raw data coming in, it looks like significant numbers of applicants include their middle name with this pattern. This may or may not be what a service wants. At best I'd say it's ambiguous what's wanted, which isn't good - fields should be clear to applicants if they want a middle name or not.

[dasarindra]

Vouching example for HMPO's passport service

[cristina-agramunt]

Hello,

I wanted to share some information with regards the capture of names and some of the issues we encountered at the Apply for a National Insurance number.

I didn't get much feedback on the community Slack as I am guessing this might be a more specific issue, but I thought it would be good to share here and register our findings.

The first months after the service went online, we noticed a "high" percentage of applicants dropping out of the journey on the "Name" screen. We also observed that many users were viewing the same error message telling them that both fields needed to be completed.

User research identified that many of our users are from foreign background. This means that many might not only have special characters on their names, but also different name composition. Many user testing rounds helped us to identify the most common issues our users were encountering and by iterating the content often we were able to create a screen that better supported our users by giving them specific instructions on how to proceed.

This was the result:

[joelanman]

@cristina-agramunt thanks for posting, I realise this is probably not your responsibility directly, but really services should support any characters that are in people's names. Is this not possible here?

[vickytnz]

The text is interesting, but it seems to be three separate prompts rolled into one?

v My name has accents or special characters

Replace these with a letter from the English alphabet. For example:

• instead of Zoe, type Zoe
• instead of José, type Jose

v I only have one name

Enter your name in both fields.

v I have multiple names which are not first names or surnames

Enter at least one name in each field

[emma-cuthbert]

Hi @joelanman - no, this isn't possible. We've checked with the developers multiple times. The back end can't accept special characters, so the choice is either to get the user to strip these out (as here) or to strip them out automatically. The tech lead opted to do the former, as the latter throws up data protection issues - we'd be changing their names without their consent.

@vickytnz - that's correct. We have users whose names include accents and special characters; we have users who only have one name; we have users who have multiple names that don't fit into these fields. Each of restrictions only applies to a minority of users, which is why we've put them in the details component rather than in hint text.

[vickytnz]

my challenge is that say for the special characters one someone probably wouldn’t think that they needed help until they got an error, and the other two situations are mutually exclusive, so why bury this all in a generic “help about this question” field rather than 3 specific details components that users might better relate to?

[emma-cuthbert]

Interesting, thanks @vickytnz. There's nothing I can see in the design pattern to say that more than one details component can be used per page, so I didn't realise this was commonly done.

[cristina-agramunt]

my challenge is that say for the special characters one someone probably wouldn’t think that they needed help until they got an error, and the other two situations are mutually exclusive, so why bury this all in a generic “help about this question” field rather than 3 specific details components that users might better relate to?

I wonder if a work around this would be to show the information after the user enters the character? As part of the error message?

[emma-cuthbert]

@vickytnz - just had a chat with my team and we're going to draft a new design and test with users. I completely agree that more targeted content will increase the likelihood of people clicking on the link - and so avoiding the error message. Thanks for raising.

@joelanman - apparently the product owner has flagged this issue with the team who are working on whatever's replacing the CIS system.

[edwardhorsford]

I wouldn't say it's changing without consent - I think I'd play back to the user 'You typed x, the closest is y, is this ok?' - I think I've seen other services in gov do this, but can't name any specifically.

[cjforms]

@emma-cuthbert +1 to what @vickytnz and @edwardhorsford have said.

I also noticed that there's a mismatch between the hint text "Enter your name as shown on the identity documents that you are using to apply for a National Insurance Number' and the text of the message. People have to enter amended names that accord with the rules that the system (unfortunately, unavoidably) imposes on them.

I'd suggest that you think about that hint text too. It seems to me quite likely that there may be a variation in the way names are shown across identity documents. For example, my birth certificate has a different surname to my passport because I chose to change my surname on marriage. This can't be unusual, and there must be many other examples.

My recommendation would be to change it to: "Copy your name as it is written on the most recent identity document that you are using to apply for a National Insurance Number' (subject to testing, obviously)

I'd strongly recommend @edwardhorsford's approach of letting them type in the name as stated on document, and then have a separate step that says something like 'Unfortunately our matching system doesn't know about accents or special characters. We plan to search using this name: [ name as tweaked for your rules ]" with an option to retype/try a different spelling. [Example, someone with a u-umlaut may prefer to change to eu rather than plain u]

[edwardhorsford]

As an aside: I expect it's common that the "official document" won’t have accents either (passports don't have them, etc), but still might expect users to try enter their name with accents if that's what their name contains.

Thinking about it some more, I think it was a Home Office service that showed the user what they'd get without accents - possibly the service for getting a Biometric Residence Permit

[joeedhorton]

Our service collects a single field "Full name" as per the pattern. In addition to the above issue where some users are giving us a much longer name than we really need, I'm seeing a minority of users only provide their first name.

I speculate this is because they're used to filling their name in two boxes so expect a second box later.

Has anyone else observed this?

Hey @edwardhorsford,

I'd love to hear an update on any iterations you made off these findings since then as I'm working with a similar use case. Did you decide to split into two inputs for first and last name or keep to full name and improve wording/guidance?