International address

[tomyems]

To discuss ways in which services ask for international addresses and whether there's any consistency that should be shared.

[tomyems]

Preview of changes: https://664b53c389a77b9234268508--hods.netlify.app/patterns/address-not-uk

Looking for feedback on:

• structure, how do the separate pages work? Too much duplication or making it easier?
• for multiple address line fields, to bold or not bold the field labels
• enough explanation, too much explanation?
• is the explanation clear and unambiguous?
• the country list (currently has no data in it), is this the right format, does it have the right name?
• what to call autosuggest/autocomplete/typeahead
• how to show autosuggest/autocomplete/typeahead in the examples - as a text input or select?

There's some broken links and typos in here, don't worry about them too much - feel free to point them out and will make sure they're fixed before putting it live

[DeborahStevenson]

Overall Comment:

Is there a way of having one page showing all of the enter address patterns? They seem to be duplicated across the 3 pages, the only difference seems to be scenarios which you could potentially explain under headers? Or it may be that you can split it by internal services and external services, although I thought the design system was predominantly for external services?

You've also mentioned about people hitting barriers. It would be helpful to give examples and show suggested error messages or hint text to help them overcome barriers?

Feedback on each page:

Address not in UK

1. Change H1: Address not in the UK
   To: Address outside of the UK
   Reason: sightly easier to read

2. Change: You can ask for addresses not in the UK in 3 ways
   To: You can ask for an address outside of the UK in 3 ways
   Reason: slightly easier to read. You could also say 'non-uk address '?
   Comment: Reading this I'm assuming there are 3 different ways of entering and address? Or do you mean there are 3 different types of non-UK addresses?

3. General comments: I wasn't clear what was meant by the radio options - consider reviewing these. The term 'valuable delivery address' wasn't clear to me. Do you mean an address for sending valuable items? Although it's more words, it may be clearer to say this way?I've not come across 'familiar address' before so wasn't clear when I would use this? The term 'a given address - least assurance' - also was not clear on what was meant by a given address. Who would give someone an address and why?

Valuable delivery address

1.Change: Valuable delivery address
To: Address for sending valuables
Reason: Clearer what is meant

2. General comment: When I clicked on valuable address - I was a bit confused by the line 'This pattern is for services where the user has a barrier to completing the service if the address is incorrect, Consider if a process to correct the address after the user has entered it would resolve this barrier.'

I was assuming it was going to be a pattern for entering an address for valuable items, so I wasn't clear that this was going to cause any barriers. Can you give examples of services like this?

3. The enter a postcode field looked very wide, I assumed it would just be postcode length - does the image need updating

4. General comment: It's not clear when to use the country pattern versus other patterns?

5. General comment: The Postcode example seems more relevant to UK addresses? Should this example relate more to the use fo zipcodes etc? Also, does this contradict what has been said elsewhere about using line 1 etc instead?

6. General comment: I think it would be helpful to define which are address look up patterns versus which are not.

Familiar address

1. Change: Ask users to provide a familiar address not in the UK
   To: Ask users to provide a familiar non-UK address
   Reason: slightly easier to read. You could also say an address outside of the UK?

2. General comment: I was slightly confused by 'This pattern is for services where there is little impact on the user for the address being incorrect or not recognised by another system.' Can you give an example of when this might be? I'd assume you always need to have the right address?

3. General comment: I wasn't clear when I would use the select a country pattern over some of the other structured and non-structured patterns? Can you clarify please? Is this mainly used on internal services?

4. General comment: The manual entry pattern looked like a UK address format with it having, Town, City and Postcode. Some overseas addresses have zip codes not postcodes. Does this need updating? This doesn't seem to be consistent with what has been said on other pages about avoiding Town etc and using line 1, 2, 3 instead? Also, is all address patterns manual? For consistency, should this be called 'Structured address'

5. General comment: The research section is showing an empty bullet list?

Record given address

1. Change H1 : Record given address
   To: Record an unverified address
   Comments: Clearer. Is the way we record an unverified address different? I couldn't see anything on these examples for a user to record that it was unverified?

2. Change: Check whether there is a need to record the data in a structured format.
   To: Decide if the address needs to be recorded in a structured or unstructured format.
   Comment: add an example of what you mean? If there is one pattern for entering an address why would they not give it in a structured way? How would we check this and with who?

3. Change: This pattern is for internal services where both:
   -there is a need to record an address that is not verified
   -staff are given addresses to record
   To: This pattern is for internal services to record an address that is not verified
   Reason: I think this summarise both the bullets? If the address is not verified then does it matter who has given the address? It seems quite a specific scenario. I wasn't clear who has given the staff an address to record.
   Comment: It says ' users find it easier to record address in an unstructured format' do we have research evidence to back this up? Also although people may find it easier to enter, is it easier to read the outputs?

4. Change: Structured address lines
   To: Structured addresses
   Reason: I don't think you need the word lines

5. Change: Their home address
   To: Home address
   Reason: We don't generally include 'Their etc' in labels

6. Comment: Consider using 'unstructured' instead of 'not structured'. Also remove the word 'their' from the screenshot - as per previous comments

[tomyems]

Amazing thanks Debbie - I've updated to https://667e7d598770a6f789ec8172--hods.netlify.app/patterns/address-outside-uk

Is there a way of having one page showing all of the enter address patterns? They seem to be duplicated across the 3 pages, the only difference seems to be scenarios which you could potentially explain under headers? Or it may be that you can split it by internal services and external services, although I thought the design system was predominantly for external services?

I considered one page showing all of the patterns, when I did this I found the page more confusing to get the message across - though I appreciate that there is some duplication when split out across three pages.

You've also mentioned about people hitting barriers. It would be helpful to give examples and show suggested error messages or hint text to help them overcome barriers?

Ah I think I meant here about the most general idea of barriers. So not necessarily hint text and error messages, but all of the possible things that might make the service more difficult for the user to complete.

Change H1: Address not in the UK
To: Address outside of the UK
Reason: sightly easier to read

Changed.

Change: You can ask for addresses not in the UK in 3 ways
To: You can ask for an address outside of the UK in 3 ways
Reason: slightly easier to read. You could also say 'non-uk address '?
Comment: Reading this I'm assuming there are 3 different ways of entering and address? Or do you mean there are 3 different types of non-UK addresses?

Rephrased

General comments: I wasn't clear what was meant by the radio options - consider reviewing these. The term 'valuable delivery address' wasn't clear to me. Do you mean an address for sending valuable items? Although it's more words, it may be clearer to say this way?I've not come across 'familiar address' before so wasn't clear when I would use this? The term 'a given address - least assurance' - also was not clear on what was meant by a given address. Who would give someone an address and why?

I've had a go at renaming and updating the descriptions for each of the three options, do you think they're an improvement?

1.Change: Valuable delivery address
To: Address for sending valuables
Reason: Clearer what is meant

Removed 'vaulable'

General comment: When I clicked on valuable address - I was a bit confused by the line 'This pattern is for services where the user has a barrier to completing the service if the address is incorrect, Consider if a process to correct the address after the user has entered it would resolve this barrier.' I was assuming it was going to be a pattern for entering an address for valuable items, so I wasn't clear that this was going to cause any barriers. Can you give examples of services like this?

The delivery address pattern is more complicated for users to complete, which could be a barrier to some users. If you don't need that level of assurance of the address then use one of the other patterns.

The enter a postcode field looked very wide, I assumed it would just be postcode length - does the image need updating

Updated

General comment: It's not clear when to use the country pattern versus other patterns?

Apologies, not sure I understood this.

General comment: The Postcode example seems more relevant to UK addresses? Should this example relate more to the use fo zipcodes etc? Also, does this contradict what has been said elsewhere about using line 1 etc instead?

We use the generic 'postal codes' which refers to 'postcode', 'zip codes' and so on. We've got:

If possible, use the country specific word for the postal code, such as 'postcode', 'zipcode', or 'Eircode'. If not, use 'postal code'. Check the country list.

General comment: I think it would be helpful to define which are address look up patterns versus which are not.

Apologies, not sure I understood this.

Change: Ask users to provide a familiar address not in the UK
To: Ask users to provide a familiar non-UK address
Reason: slightly easier to read. You could also say an address outside of the UK?

Updated.

General comment: I was slightly confused by 'This pattern is for services where there is little impact on the user for the address being incorrect or not recognised by another system.' Can you give an example of when this might be? I'd assume you always need to have the right address?

There are some services such as UKVI accounts and ETA where being able to deliver something to the address is less important.

General comment: I wasn't clear when I would use the select a country pattern over some of the other structured and non-structured patterns? Can you clarify please? Is this mainly used on internal services?

Apologies, not sure I understand.

General comment: The manual entry pattern looked like a UK address format with it having, Town, City and Postcode. Some overseas addresses have zip codes not postcodes. Does this need updating? This doesn't seem to be consistent with what has been said on other pages about avoiding Town etc and using line 1, 2, 3 instead? Also, is all address patterns manual? For consistency, should this be called 'Structured address'

I'm not sure I agree about zip code over postcodes. 'Postal code' is more generic. Some countries have zip codes, but not generally well understood across a wide range of countries.

General comment: The research section is showing an empty bullet list?

Yep. Still needs to be written.

Change H1 : Record given address
To: Record an unverified address
Comments: Clearer. Is the way we record an unverified address different? I couldn't see anything on these examples for a user to record that it was unverified?

I was trying to avoid 'unverified' - by definition if you're using this pattern it is not verified, so not sure a user would need to add anything to say it was unverified. Happy to add to the 'help us improve this pattern'

Change: Check whether there is a need to record the data in a structured format.
To: Decide if the address needs to be recorded in a structured or unstructured format.
Comment: add an example of what you mean? If there is one pattern for entering an address why would they not give it in a structured way? How would we check this and with who?

As a designer you need to consider the rest of the service, it could be that later on in the service it needs to be read by another user, or it could be that the backend systems require a structured address.

Change: This pattern is for internal services where both:
-there is a need to record an address that is not verified
-staff are given addresses to record
To: This pattern is for internal services to record an address that is not verified
Reason: I think this summarise both the bullets? If the address is not verified then does it matter who has given the address? It seems quite a specific scenario. I wasn't clear who has given the staff an address to record.
Comment: It says ' users find it easier to record address in an unstructured format' do we have research evidence to back this up? Also although people may find it easier to enter, is it easier to read the outputs?

Updated.

Change: Structured address lines
To: Structured addresses
Reason: I don't think you need the word lines

Removed

Change: Their home address
To: Home address
Reason: We don't generally include 'Their etc' in labels

Changed to a question 'What is their home address?'

Comment: Consider using 'unstructured' instead of 'not structured'. Also remove the word 'their' from the screenshot - as per previous comments

Ah interesting, I went with avoiding the prefix 'un' for showing negativity?

[basonj]

I think the introductory bullet points are a bit confusing as they are phrased currently, for example I think it's a bit unclear what's meant by 'You can ask.. for a valuable delivery'. I'd propose rephrasing something like the below:

You can ask for addresses in different ways depending on what you need to do.
You might need to:
• delver something valuable
• collect an address the user is familiar with
• collect an address the user has been given

I would suggest moving the comments about most/least assurance to the details pages, so it can be explained in more detail there.

I also wonder if 'Address outside the UK' might be more plain English than 'Address not in the UK'?

[tomyems]

Thanks, I've updated the introduction. On 'outside' vs 'not in', I thought about 'outside' but worried that 'outside' has more than one meaning. What do you think to 'Address abroad'?

[tomyems]

Updated preview: https://664f0138c01841009a39cb3b--hods.netlify.app/

[tomyems]

Preview: https://665896c1497f3a2c62aafb51--hods.netlify.app/patterns/address-outside-uk

Changes include:

• renaming of the question from 'Enter your home address' to 'What is your address?' (to match the GOV.UK design system question on addresses)
• replacing 'postcode' with 'postal code' throughout
• fixing some typos
• rename 'address not in the UK' to 'address outside the UK' (the users of this pattern, that is designers, understand outside the UK to mean abroad)
• expanded 'accented latin-based characters' to be more specific about what this means
• no bold (or govuk-label--s) for the field labels for addresses

Outstanding questions:

• accessibility sections for each page, are there any more accessibility considerations we need to add
• how do we refer to autosuggest/autocomplete/typeahead
• how to show autosuggest/autocomplete/typeahead in the examples - as a text input or select?

[simonWheatcroft]

am a full-time screen reader user and happy to provide commentary on accessibility . In terms of level of detail, do you require in-depth feedback?

For example, highlighting individual issues such as the radio buttons not being labelled? Or is there an assumption that is covered in a separate guideline?

[tomyems]

You would be more than welcome to test the pattern pages. I don't have an example of an implementation of the guidance you could test. The idea is anything useful to a designing thinking about asking about addresses - they probably don't need to know about how to make a text input accessible, as this is covered in the text input guidance. Happy to discuss if that would be helpful?

[simonWheatcroft]

Happy to give general comments on accessibility. Could you provide the latest link as a reply to this comment?

as checking https://665896c1497f3a2c62aafb51--hods.netlify.app/patterns/address-outside-uk
for me gives 404's for the seperate pages.

[tomyems]

Apologies - the links were broken, here's a fixed version: https://667e7d598770a6f789ec8172--hods.netlify.app/patterns/address-outside-uk

[tomyems]

Latest preview: https://667e7d598770a6f789ec8172--hods.netlify.app/patterns/address-outside-uk

[tomyems]

Updated: https://6682a44e45573b09690fc515--hods.netlify.app/patterns/address-outside-uk

Combined the familiar address into the top-level pattern, and now 'delivery' and 'given' addresses are 'sub' patterns.

[simonWheatcroft]

For general accessibility feedback (these issues may be captured on other design patterns): Radio buttons - make sure they are grouped and labelled correctly For address entry use HTML 5 auto fill attributes - this would provide the potential of one click form filling Ensure that required fields are communicated to assistive technologies

[tomyems]

Question: are there any adjustments in the pattern for addresses users are vaguely familiar with - so addresses of businesses, community centres, charity places (that are not places people live) - perhaps one for the 'help us improve these patterns'