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?

[NickColley]

@terrysimpson99 the Royal Mail guidance says county is not required but I imagine they're saying that assuming the user has entered a postcode. Do we know that a county is not required when a user has not entered a postcode?

[terrysimpson99]

Yes it's a reasonable suggestion that county might be useful to Royal Mail as backup to absent, incorrect, or illegible postcodes. If that were true, it would be a bold step for GDS to drop it from examples. However Royal Mail doesn't show county in their own examples of good addresses, their address tools don't use it, and guidance that county isn't required doesn't have any mention of it being conditional on a postcode. They spent years transitioning to county-free addressing and the benefit of county as a backup hasn't been mentioned in any of the discussions I've seen.

The term 'county' is ambiguous anyway. Users give inconsistent responses and may give the: 'former postal county', 'historic county', 'traditional county', 'preserved county', 'administrative county', or the adjacent county (this is common in cities that overlap boundaries). This isn't just a human failing, some machines have similar failings, for example Argos thinks Manchester is in Lancashire (it isn't).

The address lookup tool used by many government services doesn't provide county because it uses the Royal Mail database of 'correct' addresses. I quote Royal Mail guidance as the dominant letter service but other delivery services appear to be the same.

[gazjoy]

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.

@jonathaninch have you considered asking for the country and then providing a multiple text input address pattern once you know the country? This is something we are currently struggling with too.

[terrysimpson99]

Interesting. The guidance says:

• "Use a manual option such as multiple text inputs or a textarea when you are collecting mostly or only international addresses"
• "Only use multiple text inputs when you know which countries the addresses will come from ..."

In our service the default design is the UK postcode button. We make the manual option available as an alternative path even where the only valid input is a UK address. It's available as a primary path for international users and we don't ask for the country in advance. Thus we don't comply with the guidance. Would anyone like me to propose better wording for the guidance?

[terrysimpson99]

I propose removing:

• "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."

and replacing it with:

• "A 'county' field is redundant for UK addresses. Royal Mail (and other companies) do not use county to deliver mail."

Our current guidance

• introduces a condition (“as long as”) that doesn't exist in what Royal Mail said.
• contains the term 'should' which effectively contradicts Royal Mail.
• introduces a concept of 'valid address' but doesn't define what it means. If it means a letter without a county can’t be delivered then that’s not true. If it’s something else, then I’d like to know what it is.

Let's take an example (the GDS office). Plausible addresses using the county field include :

• 10 Whitechapel High St, London, Tower Hamlets E1 8QS.
• 10 Whitechapel High St, London, Middlesex E1 8QS
• 10 Whitechapel High St, London, Greater London E1 8QS
• 10 Whitechapel High St, London, London E1 8QS

I've heard it said that the county helps resolve the case where the entire postcode is missing but that isn't a reliable argument either. The example above becomes:

• 10 Whitechapel High St, London. which isn't difficult to resolve

In Bristol people will put 'Bristol', 'Avon' (which no longer exists), or even 'Gloucester' for example:

• 2 Redcliff Street, Bristol, Bristol BS1 6GR

It's possible county might be useful where the postcode is absent AND the postal town shares a name with a non-postal town AND the intended destination is the non-postal town. However, this looks like an edge case and neither this nor any other error scenario has been mentioned by Royal Mail or by the PAF advisory board (who made the decision to delete counties from the PAF).

The Royal Mail address finder doesn't provide county. See: https://www.royalmail.com/business/find-a-postcode

See also:

• "There is no need to include a county name, your letters and parcels will reach your intended recipient without one." https://personal.help.royalmail.com/app/answers/detail/a_id/81/~/how-to-address-your-mail-%28clear-addressing%29

• "But in terms of postal deliveries, the concept of counties is redundant. " https://www.formisimo.com/blog/uk-e-commerce-businesses-counties-are-gone-and-have-been-for-a-long-time/

• https://en.wikipedia.org/wiki/Postal_counties_of_the_United_Kingdom

This may appear to be a small detail but addresses input is a very common pattern so it's worth debating opportunities for simplification. Happy to discuss this further.

[NickColley]

@terrysimpson99 thanks for writing that up, we'll discuss it as a team and get back to you!

[timpaul]

Thanks for the thorough write-up @terrysimpson99. We're going to investigate this, and other potential improvements to the pattern, as part of this story: https://github.com/alphagov/govuk-design-system/issues/1190

[terrysimpson99]

The pattern has a mismatch between visible and invisible field labels. We decided this isn't necessary because in our services we can use 'Address line 1', 'Address line 2' etc then 'Postcode'.

We try to keep the visible and invisible label the same unless there's a good reason otherwise. It's simpler for all parties in the product lifecycle because errors/inefficiencies in legacy invisible code have sometimes been causing problems without people knowing. https://adrianroselli.com/2017/02/not-all-screen-reader-users-are-blind.html

Does anybody else use: 'Address line 1' 'Address line 2' etc 'Postcode'

[benraine]

At DWP, we recently tested the manual address entry with users where we were asking for as much information as someone could provide about a person's address. For this design all fields were optional. In our usability testing we found users were omitting the house number, even when they knew what it was. We thought this issue could be caused by the labels being "building and street" so we changed the first two labels to "address line 1" and "address line 2". We saw no issues in our next round of usability testing. This could be the niche way we're asking for as much information in all optional fields, but felt it was worth raising.

[kellylee-gds]

Related pattern https://github.com/alphagov/govuk-design-system-backlog/issues/225

[abbott567]

Hi Everyone, when testing a service using Dragon14 we found that if you live at number 2, in any other mode other than 'spelling mode' when trying to type your address Dragon would actually move from field one to field two instead of inputting the number 2.

In spelling mode it worked, and if you say 'numeral 2' it worked. Presumably the issue is linked to the 2 of 2 text hidden in the label?

I know Dragon 14 is quite old now, and the pattern is working if you use particular commands, but thought it was worth raising as it could be confusing for people who don't know the commands inside out.

[edwardhorsford]

Hi Everyone, when testing a service using Dragon14 we found that if you live at number 2, in any other mode other than 'spelling mode' when trying to type your address Dragon would actually move from field one to field two instead of inputting the number 2.

In spelling mode it worked, and if you say 'numeral 2' it worked. Presumably the issue is linked to the 2 of 2 text hidden in the label?

I know Dragon 14 is quite old now, and the pattern is working if you use particular commands, but thought it was worth raising as it could be confusing for people who don't know the commands inside out.

@abbott567 I wonder if this must be an issue for many address inputs for Dragon 14? presumably lots of ones label their second line similarly.

[emma-cuthbert]

Hi all, I'm sure this has been discussed before, but I couldn't find any references to it. What happens if a user doesn't know their postcode or enters their postcode and doesn't get a match? There's currently no workaround for them - this prevents them being able to move forward.

Could we consider adding a direct link from the screen where they enter a postcode to the screen where they manually enter their address? The link would say something like 'I don't know my postcode'

Thanks Emma.

[terrysimpson99]

HMRC has a postcode lookup microservice. It has a link to bypass the postcode field: 'Enter the address manually'.

---

[image: image.png]

---

If no address is found, it shows the link again and allows the user to enter a different postcode:

Github for the microservice is at: https://github.com/hmrc/address-lookup-frontend

On Thu, 8 Apr 2021 at 14:45, emma-cuthbert @.***> wrote:

Hi all, I'm sure this has been discussed before, but I couldn't find any references to it. What happens if a user doesn't know their postcode or enters their postcode and doesn't get a match? There's currently no workaround for them

• this prevents them being able to move forward.

Could we consider adding a direct link from the screen where they enter a postcode to the screen where they manually enter their address? The link would say something like 'I don't know my postcode'

Thanks Emma.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alphagov/govuk-design-system-backlog/issues/31#issuecomment-815837266, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALO4PWOMQCRHBT3MWC6GCYTTHWXPDANCNFSM4ELRHRTQ .

-- Regards Terry Simpson User Researcher

[emma-cuthbert]

Thanks Terry - the first screenshot isn't displaying for me. Could you repost or send to me directly (email or slack both fine)? Thanks.

[terrysimpson99]

I'm reposting the image that shows 'Enter the address manually'. Let me know if you can see the image now. Also let me know if you can view the actual microservice interface at https://www.qa.tax.service.gov.uk/lookup-address/test-only/v2/test-setup [image: image.png]

On Thu, 8 Apr 2021 at 16:19, emma-cuthbert @.***> wrote:

Thanks Terry - the first screenshot isn't displaying for me. Could you repost or send to me directly (email or slack both fine)? Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alphagov/govuk-design-system-backlog/issues/31#issuecomment-815909860, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALO4PWMCS4MJGXA2CIGNVU3THXCQ3ANCNFSM4ELRHRTQ .

-- Regards Terry Simpson User Researcher

[emma-cuthbert]

Thanks Terry - still can't see the image, unfortunately :( You can send it to me on Slack or at emma.cuthbert@engineering.digital.dwp.gov.uk

Also, clicking the link to the qa.tax.service returns a '404 - authorisation required' message for me

[ntothen]

Has anyone tested single field address auto-complete e.g. https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete-addressform

or https://alphagov.github.io/accessible-autocomplete/

[terrysimpson99]

Interesting example from the passport service 'Confirm someone's identity:

[jeanesims]

We're looking at improving the quality of the data we collect and what data items can be used to match customer records across data sets, including outside the department. It seems that the UPRN (location reference) is very useful in matching addresses across different govt data sets. https://www.gov.uk/government/publications/open-standards-for-government/identifying-property-and-street-information Is there any way that the design system could advise teams that are using address look-ups which address data they should be using? Should we all be using AddressBase (and UPRNs)? I've heard some teams use Melissa API. Or does it not matter which one service teams use?

[christopherthomasdesign]

Just posting an update of recent activity on this pattern.

Thanks to @terrysimpson99, we recently changed the address field labels to use an ‘Address line n’ format rather than ‘Building and street’. The Design System Working Group unanimously approved this change.

Around the same time, we also removed the county field. This was based on the fact that the Royal Mail don’t use counties for posting things.

However, based on the Working Group’s feedback, we’ve decided to add the county field back into the address pattern, making it optional instead. This change should appear in the next few days. We’re including an optional ‘county’ field because it can be useful for reasons other than posting things.

For example:

• some users attach a sense of regional or personal identity to a county, which may be relevant to some use cases
• it can help people plan journeys to an address, especially where they need to distinguish between towns or villages with similar names
• even if you’re collecting the address solely to post things, you might need it for another purpose (that’s lawful under GDPR) in the future

We’ve also added guidance to remove the county field if you’re sure your users and your service will not need it.

[anniecrab]

Hi all. I'm wondering if the example error message on the address pattern page ('Enter a real postcode') actually meets the guidance for error messages (explain what went wrong and how to fix it) or if there could be a better example given here of a self-contained error message.

If you know what a postcode is, where to find it and how to check it, then it will be enough to tell you that you got it wrong. But not everyone will, and just saying 'that's wrong!' feels less helpful than it could be in terms of the wording (though I get it's intended primarily as an example of styling, it's still presented as a pattern).

We need to rewrite and test this in my service so I've been looking around for other examples, for example Find your local council which prompts people to check the postcode and links to the Royal Mail postcode finder, and just wanted to suggest rethinking it as an example.

[emma-cuthbert]

@anniecrab - For this reason, I changed the error message to: Enter a valid UK postcode using only letters and numbers in the format NE98 1FX

We've had feedback that examples help (most of our users aren't from the UK)

[StephenGill]

Hi - it's intentionally an exception to the rule about explaining how to fix the problem.

If you can clearly explain what's gone wrong in an error message, that's ideal. But sometimes it's not possible - for example, I'd say the rules about what makes a valid postcode are too complex to play back in an error message.

The idea is to prefer error messages that are clear, and get across the basic idea - "something is wrong with the data you've entered, look at it and fix it" - even if they're less specific about what the problem is.

[anniecrab]

@StephenGill I hear that, but I think 'enter a real thing' when someone has just tried to do that is not as much help as we could be giving people, so am not convinced it's the best example to have there. Could something else go in instead?

[terrysimpson99]

Ideally, error messages should make sense for each of these three scenarios (1) the format or checksum fails (2) it passes (1) but doesn't match our version of the official dataset (3) it passes (2) but is not in the official dataset

[StephenGill]

(2) and (3) are problems that can't be corrected by the user, so feels like they should be handled using a different pattern?

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.

On Thu, 5 May 2022 at 13:05, terrysimpson99 @.***> wrote:

Ideally, error messages should make sense for each of these three scenarios (1) the format or checksum fails (2) it passes (1) but doesn't match our version of the official data (3) it passes (2) but is not in the official dataset

— Reply to this email directly, view it on GitHub https://github.com/alphagov/govuk-design-system-backlog/issues/31#issuecomment-1118470194, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABI6BP3FPVJ7KKGA4DHXQPLVIO2PTANCNFSM4ELRHRTQ . You are receiving this because you were mentioned.Message ID: @.***>

--

Stephen Gill Content lead, services programme Government Digital Service

T: 077962 98949

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