Designing Name Fields

Practical guidance for choosing which name fields to collect, how to label them, and which Name Done endpoints to use in your forms.

Why this matters

Names are personal. People have different names for different contexts — a government name on official documents, a nickname friends use, a previous name from before marriage or transition, a pseudonym for privacy. The fields you design determine which of these names you receive, and how your users feel about giving them.

There is no single right way to ask for a name. The best approach depends on your context: what you will do with the name, how formal the relationship is, and whether you need to interface with third-party systems that have their own requirements.

Collect only what you need

Under UK GDPR, you should practise data minimisation — collect only what is necessary for your purpose. Before adding a name field, ask yourself: where will this name be used, and how important is it that the information is high-fidelity?

Single field vs. separated fields

Single “Full name” field

The GOV.UK Design System recommends asking for a name as a single field labelled “Full name” with no input validation (no regular expressions). This is the most socially flexible approach — it lets the user decide how they want to be referred to.

• Best for: newsletters, invitations, informal sign-ups, any context where the user gets to decide what you call them.
• Benefits: works for any name format, including mononyms, multi-part surnames, and names with special characters.
• Drawbacks: you cannot reliably split the name into first and last parts later — some cultures put the family name first, and some people have only one name.

1import { createClient } from "@namedone/autocomplete"
2​
3const nd = createClient("nd_...")
4​
5// User types "john s" → "John Smith", "John Stevens"…
6const { results } = await nd.fullNames("john s")

Separated first name + last name

More rigid, but necessary when you need to refer to someone in multiple social contexts (formal letter, email greeting, envelope) or when interfacing with third-party systems that require separated names.

• Best for: official documents, credit checks, passport booking, any context where you need to index or search by surname.
• Benefits: easier to index, search, and sort. Enables formal address patterns (Mr Smith, Dr Jones).
• Drawbacks: fails for cultures where the family name comes first (Japanese, Korean, Hungarian), cultures with double surnames (Spanish, Catalan, Portuguese), and people with only one name.

1import { createClient } from "@namedone/autocomplete"
2​
3const nd = createClient("nd_...")
4​
5// First name field
6const { results: firstNames } = await nd.firstNames("jo")
7​
8// Last name field
9const { results: lastNames } = await nd.lastNames("sm")

Labelling your fields

The GOV.UK style guide recommends different labels depending on your audience:

• UK audience: “First name” and “Last name” are fine.
• International audience: “Given names” and “Family name” are more appropriate (assuming the person has a single family name — not universal).
• Middle names: if you collect them, make the field optional but do not label it as “optional” — the GOV.UK guidance says optional fields should be allowed to be empty without being called out.

Titles and privacy

Asking someone to disclose whether they are “Mr”, “Mrs”, “Miss”, or “Ms” can reveal their gender and marital status. If you do not need a title, do not ask for one.

• Mx is a gender-neutral title that does not reveal gender or marital status. Name Done includes it in the titles list.
• Dr, Prof, Rev are also gender-neutral — they reveal qualifications or roles, not gender.
• If you need a title for formal correspondence, use the formal names endpoint, which combines titles with names automatically.

Validation

Do not use regular expressions to validate names. Names can contain letters outside A–Z (à, ñ, ü, ç), apostrophes (O’Connor), hyphens (Smith-Jones), spaces (van der Berg), and even characters from non-Latin scripts (Arabic, Chinese, Japanese). The classic article Falsehoods Programmers Believe About Names lists 40 common assumptions that turn out to be wrong.

Instead of regex validation, focus on:

• Security: protect against SQL injection and XSS at the storage and rendering layer, not at the input layer.
• Length limits: if you need a maximum length, set it generously (255 characters is common). Avoid minimum lengths — some people have one-letter names.
• Character set: accept any Unicode character. Do not restrict to A–Z.
• Third-party requirements: if you are forwarding the name to a third party (e.g. a credit agency or passport system), validate against their specific requirements, not a generic regex. For example, the ICAO Machine Readable Travel Document standard defines what characters are allowed on passports.

Cultural considerations

If your form serves an international audience, be aware that name structures vary significantly across cultures:

• Family name first: in Japanese, Korean, Chinese, and Hungarian cultures, the family name precedes the given name. For example, South Korean pop star PSY is Park Jae-sang, where Park is his surname.
• Double surnames: in Spain, Portugal, and many Latin American countries, people have two surnames — the first surname (apellido paterno) from the father and the second (apellido materno) from the mother.
• Connector words: in Catalonia, surnames may be joined with “i” (e.g. Cèlia Puig i Torà). In the Netherlands, “van” and “de” are common prefixes.
• Mononyms: some people have only one name, particularly in parts of Indonesia and Iceland.

If you serve an international audience, prefer a single “Full name” field. If you must separate, use “Given names” and “Family name” rather than “First name” and “Last name”.

Which Name Done endpoint should I use?

Further reading

• Falsehoods Programmers Believe About Names — the classic list of 40 assumptions about names that turn out to be wrong.
• GOV.UK Design System: Ask users for names — the UK government’s guidance on collecting names in forms.
• ICAO Document 9303 — Machine Readable Travel Documents standard, for names that need to match passports.
• ICO: Data minimisation — the UK GDPR principle of collecting only what you need.