Addresses

[govuk-design-system]

Ask users for addresses

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

[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?