Addresses

[govuk-design-system]

Ask users for addresses

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

[dashouse]

For some time (pre Design System) our recommended multi-input pattern for entering an address has contained two inputs for "Building and street", with the second input having a visually hidden label (as well as visually hidden 1 of 2 and 2 of 2).

This second input is to support users that need to enter a Company name, building name, floor, department as well as their street address.

We are wondering if anyone who has tested this pattern has seen any issues with visually hiding the second label?

[nubz]

I am struggling too with the hidden label concept - when there is an error in that field we are trying out error messages that reference Building and street (line 2 of 2) as the field descriptor in the message.

Also quite challenging is how to communicate that the second line is optional? (In our service line 1 and postcode are the only required fields).

[MahmoodAkhtar]

If the 2nd field in the address (address line 2) is an optional field then you could have "Optional" as hint text above it perhaps?

JSFiddle example

[timpaul]

Dropbox Paper audit

The research below was taken from a Dropbox Paper document, which was reviewed and archived On 8 Jan 2019 by the Design System team.

The aim was to reduce the number of places containing guidance and code by:

• migrating relevant, useful content into the Design System itself
• recording important research findings in the community backlog
• removing the original Dropbox Paper page

If you need to, you can see the original Dropbox Paper content in the internet archive.

Research

Open Address UK did some address entry user research  - qualitative testing (9 users) of free text box (which they describe as 'one single address field') against multiple fields. The results were mixed: some users preferred free text box, others preferred multiple fields. Users were faster with free text box, but ended up with more errors in the address. They made more mistakes to start with on multiple fields, corrected them as they moved address elements around, and ended up with fewer errors in the end.

The forms they used had some usability errors such as use of placeholders for example text, so those usability errors may have influenced the results.

Related links

http://www.formsthatwork.com/internationaladdresses
http://www.royalmail.com/personal/help-and-support/How-do-I-address-my-mail-correctly
http://www.uxmatters.com/mt/archives/2008/06/international-address-fields-in-web-forms.php
http://www.bitboost.com/ref/international-address-formats.html#Formats

[danielle-allen]

I have a question around examples of overseas postal or zip codes. I'm looking to add an example that isn't UK as our users shouldn't have a UK address but there isn't anything that I can find in the design system giving an overseas example that we can use.

[terrysimpson99]

Try the Universal Postal Union:
http://www.upu.int/en/activities/addressing/postal-addressing-systems-in-member-countries.html

and select "Guide to the headings used in country sheets"

Hope that helps

[danielle-allen]

This is really helpful, thanks! It's great for checking if our validation for field length stands up. It still leaves a bit of a question mark around examples we can use though.

[terrysimpson99]

I'd like to create a pull request add text to https://design-system.service.gov.uk/patterns/addresses/
The text would describe how to handle input to a postcode field. I'm aware of issue #82

Does anybody object?

[hannalaakso]

Hi @terrysimpson99 thanks for your message. Would you mind expanding a little bit on what the PR would contain? Would it be a hint text for the user, or some documentation for the service team on how to validate postcode input?

[terrysimpson99]

Hi @hannalaakso
The latter. I'd like to add guidance about validation. Inspirations for good validation include:
https://www.gov.uk/find-local-council
https://courttribunalfinder.service.gov.uk/search/postcode
https://www.royalmail.com/find-a-postcode

Those services accept characters that aren't part of a postcode. For example: "ch1-1aa", (hyphen) "ch1 1aa" (extra space within code), "ch1 1aa" (space before code), "ch1 1aa,"(comma), " ch1 1aa." (period). In addition, some services have a limit on input characters that turn "ch1 1aa" into "ch1 1a" and then tell the user it's invalid.

Anyone that received an email or text message with those examples would accept them as postcodes and wouldn't send a message back to the user saying they hadn't provided a valid postcode.

I won't name examples of unnecessary rejection but there are sufficient to make it worth mentioning.

Hope that helps.

[hannalaakso]

Thanks @terrysimpson99 we've discussed your proposal with the team.

It would be great if you could submit a pull request as this will give us an opportunity to review the changes and discuss them with other teams.

It's hard for us to say whether this will work as guidance in a wider government context without seeing the actual changes.

Sorry if that's not too helpful! We're really grateful for your offer to help us improve the Design System 🙌

[terrysimpson99]

Thanks. I'll submit a pull request.

[jonathaninch]

Hi all - is there any reason we don't have hint text (and a more specific error message) for postcodes? With email and phone numbers we are giving examples in hint text and in error messages (e.g. "Enter an email address in the correct format, like name@example.com" or "Enter a telephone number, like 01632 960 001, 07700 900 982 or +44 0808 157 0192"), but the best we're offering users for postcodes is "Enter a real postcode" with no guidance as to what a 'real' postcode looks like, what they might have incorrectly entered, etc?

[jonathaninch]

What is the recommendation for capturing addresses which may or may not be non-UK (e.g. if we ask for a contact address and there's no guarantee it will be in the UK)?

The address standards says we should use (a) address lookup (but this doesn't usually work with non-UK addresses), (b) multiple text inputs (but this isn't recommended for non-UK addresses where we don't know the country and therefore the format) or (c) textarea (which we can't use if we need to use separate elements of the address at a later point).

That doesn't seem to leave any useable option for capturing a non-UK address?

[terrysimpson99]

If you look at https://design-system.service.gov.uk/patterns/addresses/
you'll see some guidance such as "Address lookups generally only work for UK addresses. Use a manual option such as multiple text inputs or a textarea when you are collecting mostly or only international addresses". There's more if you look further down.

[jonathaninch]

If you look at https://design-system.service.gov.uk/patterns/addresses/
you'll see some guidance such as "Address lookups generally only work for UK addresses. Use a manual option such as multiple text inputs or a textarea when you are collecting mostly or only international addresses". There's more if you look further down.

Thanks Terry, but further down it then says you should only use multiple text areas "when you know which countries the addresses will come from" (which we don't) and "use a textarea if...you do not need to...use specific sub-parts of the address" (which we do). Hence why we seem to be stuck in a loop of address pattern options that we shouldn't use.

I'm surprised that, considering how many services might need to capture an address which could be either UK or non-UK, there hasn't been a catch-all pattern look at at some point.

e.g. Amazon used to have a generic form (not sure if they still do):

[terrysimpson99]

The example shows a field marked 'County'. For some time now, the county hasn't been required for addresses. When asked to state their county, people use a variety of terms for the same thing (I can give examples if you want). I think it's visual and task clutter for the user. (1) I propose we don't use county in examples. (2) I propose the guidance is update to recommend that county isn't used. What do you think?

[mrkwrght]

We have been doing some work on my current service around bringing things onto pattern with the design system. we noted that currently our Address lookup is off pattern but the current address lookup pattern has a select list within it.

A select component according to the design system should only be used as "last resort in public-facing services because research shows that some users find selects very difficult to use"

I'm wondering if this has been thought about because currently, the design system is contradictory.

[gunjam]

We've been experimenting using radios and I've mocked up a working version with real data, but it's a work in progress. Get a fishing licence already does this I believe.

[ch-dclarke]

On the subject of international addresses, I would suggest that there is a toggle for uk/non-uk address where either could be possible. UK addresses needs to use postcode lookup, of course.

For non-uk addresses, there are many internationalisation issues.

Separating a non-uk address into separate fields is problematic in general, particularly if used to send any mail to.

1. address lines may appear in a different order to the ones we use in the UK. e.g. Japan has the postcode, town, prefecture (effectively a county) then country in that order.
2. Some countries have regional breakdowns that are very different to the UK.

Accepting international addresses means that we potentially should accept the full range of characters from a recent Unicode Standard.

1. End to end systems will need to be tested for round-tripping the addresses from input to storage to output, without corruption.
2. This may then cause difficulty for manual handling of the addresses, if people reading them don't have the expertise in scripts that have been used.

[terrysimpson99]

Royal Mail says: "There is no need to include a county name, your letters and parcels will reach your intended recipient without one. If, however, you'd prefer to include a county name, you' are welcome to do so." See 'Address format in detail' at: https://personal.help.royalmail.com/app/answers/detail/a_id/81/~/how-to-address-your-mail-%28clear-addressing%29

The GDS current guidance makes it mandatory to include a county field: "Royal Mail does not need a county as long as the town and postcode are included. You should include an optional county text input so that people who do not know their postcode can give a valid address.".

I propose those two sentences are replaced with: "Royal Mail says there is no need for county name in addresses."

Comments?

[NickColley]

@terrysimpson99 feels in line with trying to ask users less information, do we know what impact removing county name has on successful delivery?

[terrysimpson99]

Yes. That's a good scenario and a good error message. Thus tell the user we haven't been able to find something or it doesn't match our records.

I'm not keen on terms like 'valid' or 'real' or derivatives.

[anniecrab]

For example - the covid shielding service had validation to check that the
postcode format was correct. But if it failed to match, the user was taken
to a page saying something like "sorry, we can't find your postcode in our
records: please contact your local council". NB in this case
matching a postcode was essential to providing the service.

I think it's worth noting that - as Stephen's comment here illustrates - there are different types of validation. Such as:

• Validating the pattern of characters entered and returning an error if that pattern cannot be a full, valid postcode (for example if the user only enters the first half of their postcode)
• Validating the exact postcode against a list of records associated with postcodes and returning an error if you do not have a record for that postcode, regardless of whether it exists
• Validating the exact postcode entered against a database of all postcodes and returning an error if the postcode definitely does not exist

Even if 'Enter a real postcode' was a useful error message, it would arguably only be appropriate in that final scenario where you are checking if the postcode actually exists. It would be good if the guidance in the design system encouraged people to think about this a bit more.

I'm working on error messages for a postcode search where we do the first thing (validate the pattern of characters entered and return an error if it cannot be a full, valid postcode) and then the second thing (return any records associated with the postcode entered, or explain that we don't have any).

We're trying the following for the first thing:

Postcode is too short (for example, only the first half of their postcode):
Enter a full UK postcode in the format LS1 4AP

User entered characters other than letters or numbers:
Enter a valid UK postcode using only letters and numbers in the format LS1 4AP
(Note: we accept postcodes with or without the space)

Any other issue:
Enter a valid UK postcode in the format LS1 4AP

We're using LS1 4AP because it's the address of one of DLUHC's regional offices. This will change to our Cardiff office postcode in the Welsh version of the service.

For anyone who's not seen, this is a useful guide to postcode formats, for example how long or short they can be.

[StephenGill]

Maybe it's useful to make a distinction between:

• validation (ie checking whether the data the user has entered is 'valid' according to a formula (usually expressed as regex)
• record matching (ie checking whether the data the user has entered is consistent with data from another source)

The type of thing you'd pick up through validation should be the type of thing that's within the user's power to correct - for example, a typo or transcription error - someone entering a '0' as an 'O'. So the on-page error message pattern is appropriate, because the action it's promoting is "look at the data you've entered and correct the problem".

Whereas problems you pick up through record matching probably aren't ones the user can correct. So you'd probably want to use a different approach - showing them a separate screen giving them a different way to proceed. Or failing that, an 'outcome' screen telling them that they're not able to continue with the service, and what they should do next - eg call the service provider.

[anniecrab]

Yep agree with all of this and it's what we're doing. Just don't see how 'Enter a real postcode' is helpful for any of these situations and musing on some more ways in which it's probably not the right solution to have in the design system.

[terrysimpson99]

The following scenario

• User entered characters other than letters or numbers

can be eliminated, or at least the associated error message. We normalise the user input: strip out anything that is not a letter or number prior to validation. Removing unwanted characters is something that we do for many of our fields. In fact guidance says you should do this.

[emma-cuthbert]

The following scenario

• User entered characters other than letters or numbers

can be eliminated, or at least the associated error message. We normalise the user input: strip out anything that is not a letter or number prior to validation. Removing unwanted characters is something that we do for many of our fields. In fact guidance says you should do this.

I work on Apply for a NINo: we're don't remove characters when creating a National Insurance record in CIS. Instead, we ask users to remove them when they enter their name / address through our service.

The reason for this is that we don't want to create a record with a name that doesn't match the name the user entered - we'd be changing the data they input, which our lead dev has said would create issues with data integrity.

If they have a name like José, it's easy to strip out the accent and create the NINo record as 'Jose'. But what if their name contains a Norwegian diphthong (æ) or other non-Latin characters? It's not for us to make the decision about how a name should be translated into English. Sometimes you can't even do a letter-for-letter translation - e.g. 'Алексей' (7 letters) is 'Alexei' (6 letters) in English.

[edwardhorsford]

A lot of this depends on what the data is to be used for. There's probably good cases where you can strip characters or normalise diacritics. You'd often want to do this when comparing / matching regardless.

But there'll also be lots of cases - people's names - where you shouldn't alter anything because it's a perfectly valid name.

Most services should store and preserve diacritics or other characters if those exist in the user's names. I know this isn't always possible though - for instance the international passport standards only allow basic latin alphabets plus a handful of punctuation.

[anniecrab]

We need to know exactly what postcode someone is trying to search for, so guessing what they mean is unlikely to be helpful and there's a limit to what we can do with stripping out characters as a result. This isn't a common error for us that we know of in any case.

[anniecrab]

Also: a colleague mentioned another type of postcode error to add to my list above: when postcodes relate to geographical areas that are entirely not covered by the service (for example in Scotland, or there are UK postcodes for places not even in the UK). Worth noting somewhere!

[martinwake]

Are there any plans to update or remove the postcode lookup example on this page? It uses a Select component which has been advised against for several years now, but this isn't mentioned on this page; people will still build lookups following the "GDS pattern" as shown on this page and then independently discover the issues with Selects themselves.

[gazjoy]

Just an update regarding the address finder (postcode lookup). We are considering design options for "Apply for a Blue Badge" that do not use a <select> component. We're currently trying to answer "how many addresses could there be in one postcode?". We have found an example containing 165 addresses. Pushing 165 options through a <select> feels like a bad user experience if we think about screen reader users and also those with reduced fine motor control trying to select an option on a touch screen device.

I have created a codepen which shows real data examples of UK postcodes with large numbers of addresses.

[stevenjmesser]

Thanks @gazjoy. The GOV.UK Publishing team working on /find-local-council have a similar issue, so I'm hoping they can share their designs so far.

[martinwake]

At DWP we've developed a basic address lookup pattern using radios instead of selects: https://design-system.dwp.gov.uk/patterns/find-an-address

Radios of course don't solve the "many results" problem by themselves because a long list of radios is still less usable than a short list, but we think it's an improvement over a Select component and is open to enhancement with eg grouping of results, further filtering questions, typeahead etc.

@gazjoy @stevenjmesser we found this to be a good source of test cases for address data: https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/

[mgilgar]

I am working on a ticket to update the way we validate postcodes and I am using this https://design-system.service.gov.uk/patterns/addresses/#allow-different-postcode-formats as a reference.
The main change for us is allowing spaces, full stops, hyphens between any character/ number.
Our service consists of a public facing website and a backend admin tool. From the admin tool, we allow the admin users to search by postcode. In the client tool, the user has to submit the postcode. The problem happens if the user of the client tool submits the postcode like this "T - k 9 , 5 g H", assuming that was valid, how do you recommend to store it in the database? If we store like that it will not only not be readable but also not searchable by the admin user (maybe there is a powerful search capability to search that). I think we have to normalise/ sanitise the name before storing that in the database, but then when we show the user their input in the summary page, it won't be what they have entered which will feel odd to their eyes. From one hand, I think that should be alright but if I was a user, I would prefer to know/ control what is actually stored in the database (why the system will change what I have written without my consent?).

[joelanman]

@mgilgar I would have a normalise step to store them all in the same format. So accept a wide range of formats, but store one format. I don't think users would mind in this case, but you could always test it

[mgilgar]

Thanks @joelanman

[jeanesims]

Is there a way to order results so that they are in numerical order for flats? Ie Flat 2 here comes after flat 19 because 19 has a 1 in it? Is is there a way a user can easily enter and find a flat?

[jeanesims]

Also if this is the govt standard for location should this guidance be part of the design system?
https://www.gov.uk/guidance/access-free-address-data-using-addressbase

[JillRichardsonPratt]

The spacing between the H1 and address line 1 label is slightly smaller (margin-bottom 15) than the spacing between each address field (margin-bottom 20). Could the margin-bottom on the legend wrapped around the H1 be slightly increased so it looks more even?

[fred-jackson]

Please can we publish an international version of the address page so that I don't have to keep telling designers that it should be Postal code rather than Post code.

[CharlotteDowns]

We've just added some guidance on how to 'share findings about your users' with us 📝. This will help us learn more about how your users enter addresses within your service.

[PhiSolirius]

I've been accessibility testing services and this seems to be an issue that comes up quite often:

The drop-down list for the address field doesn’t zoom properly on certain browsers and tablet and mobile devices. When zooming in, the main content zooms correctly, but the list of places in the drop-down remains small, making it difficult to read for users with visual impairments. This is not an issue when zoomed in on desktop devices.

Is this something that is fixed from GDS team?

[stevenjmesser]

Also if this is the govt standard for location should this guidance be part of the design system? https://www.gov.uk/guidance/access-free-address-data-using-addressbase

Yes, I think this should be part of the guidance for addresses. I'm now working at MHCLG so I'd be happy partnering with some people to write the guidance, proposing a content change to the design system when ready.