Find an address

[martinwake]

Hello, we'd like to use this open discussion to talk about the Find an address pattern in the DWP Design System. (Original community backlog item with background and discussion)

Please use this discussion to share any questions, research, insights, experiences or problems with this pattern that you think might be useful for others.

We're particularly interested in these questions:

• Do users need tools to navigate long lists of results? If so, how do filtering, pagination and other solutions compare?
• How have services balanced the user need for manual entry with service needs for data quality? Is there an approach that can meet both these needs?

[mrnil]

The various elements on the page may be accessible. However, this ceases to be the case when there are 100 addresses listed on the page. It’s a grand plan when you have half a dozen or a dozen addresses, but the display and the controls to select the correct address from a large radio button list quickly become a problem for usability and accessibility past a handful of addresses.

Historically and consistently working with clients and customers of the likes of large pharmacies, online stores and electrical grid maintainers it was found that this was appalling to use. It gets even worse when you start trying to consider some of the nuances like flats within building blocks and so on.

You've also added huge complexity of usability and accessibility when you need to introduce pagination in to the list of addresses.

Please provide all the use cases that you've tested.

[danhowarthgov]

Does the pattern use a standard dataset for the address lookup? If so, is it possible to test the dataset with problematic addresses like flats within building blocks, and postcodes and streets that will return lots of results – to assuage @mrnil's concerns?

If there isn't a standard or recommended dataset, perhaps there ought to be.

[martinwake]

Thanks @danhowarthdwp and @mrnil

@danhowarthdwp - no, for now we’re not recommending a single address data source because service teams might need to use different ones. This might well be something we do in future though, along the lines of the ONS pattern which integrates with their own Autosuggest component and in turn their own API.

This is related to @mrnil’s point about long lists in fact - the performance of this design pattern in a service will always depend on both the quality / number of results returned by the data source and how well it matches the needs of the specific user group, so some design choices have to be left up to each service.

We anticipate that long results lists might be a problem in some implementations (as we say in the documentation and in the main post above), but this does depend on the data source and user group. In our background research we haven't seen serious usability problems from services using this pattern, but this doesn’t of course mean these problems are nonexistent and we do actively want more research on this.

Possible ways to manage long lists include pagination and further filtering questions (asking for more information to reduce the list) but we need more research before recommending one solution over another in all cases so we're not doing that here.

@mrnil on your general point about using a list of radios: the need this pattern aims to fill is that there are known accessibility issues with the Select component as illustrated in the GOV.UK pattern, so teams currently developing address lookups need an alternative. The other main option would be a typeahead/autocomplete and that is something we want to explore, but we need more information (and hopefully evidence from live running services) on doing that accessibly and making it work for users without Javascript.

[mrnil]

You have to use the DWP Address Service to fill the address data in the address look up. Teams must not create or use their own address data.

Perhaps, rather than build a whole new journey, improving the autocomplete / typeahead would be a better use of time and effort.

The accessibility and usabilty of this Royal Mail post code look up is very high from what I can see
https://www.royalmail.com/find-a-postcode

They must use an lookahead like this for a reason?

[JodiB-TPR]

From what I can tell, the Royal Mail autocomplete doesn't have a JS fallback. It doesn't even give the user an error message if JS is turned off. It's simply a field they can type into but they can't perform any action with it.

[umair313]

Hey, where we can find the APIs to use I didn't see it anywhere on this page. https://design-system.dwp.gov.uk/patterns/find-an-address

[jonhurrell]

Hi, it's a closed internal API. The pattern should hold up with any other address API.

[mattia-gobbo]

From the UCD point of view, the flow seems to work really well for users.
Although, from the development point of view this has been really difficult to be implemented using the CASA framework (our developers managed to get the basics working but, for example, the not make the Back links working completely when user come from CYA page).
This is mainly due to the fact that CASA is built to follow a linear journey, while the address lookup is not linear (e.g. if user want to input address manually).
Ideally, considering there is such a common use case, it would be helpful to have a CASA feature/plugin that implement this flow.

[edwardhorsford]

I'd like to thank the folks at DWP for this pattern. It's excellent and well thought through - it’s been very handy whilst prototyping my service's lookup.

I have made a few changes that I feel improve the accessibility and usability and would like to share for consideration.

Search page

This currently has a line of text with link. My concern is that this is not semantically linked to the question - it's added using a component argument that I don't think is intended for content like this. If it gets linked as a hint, then we should be avoiding interactive elements - as they wouldn't be usable by a screen reader in forms mode.

This is what I'm exploring:

No results found

Have removed the line You can search again or enter the address manually. - it seems superfluous as the links after are clear.

Confirm page

Have removed the line showing the count of results - it doesn't seem relevant after selecting the address.

I've also added support for editing the address - if you've come here directly because there's 1 result, it may be 95% correct but need adjustment. Similarly if someone commonly knows their address is slightly wrong, this supports them if they select the close address.

Here's what I'm exploring:

Other

Potential mistakes in content:

• The flow diagram misses a link between lookup and manual entry
• The guidance says to use sentence case, but in this scenario, I believe title case is more appropriate - the actual examples are using title case anyway. For my prototype, I have used the titlecase package with a few hardcoded overrides.

Suggestions for the guidance:

• Could talk about how to do the filtering well - eg you want to match 50 to 50 and 50A, but not 500.
• Could talk about sorting results. The default order from OS Places will be poor, especially for flats. It's non-trivial to sort well when you are considering building numbers, names, and that numbers don't sort numerically in many systems. I've worked on some JS to ensure addresses sort nicely (will share separately)
• Could talk about how you get to the nice readable x line address format. PAF gives you 10 fields that are tricky to combine to make a nice result. For my prototype I have used the uk-clear-addressing package to format the address, and this is then used to compile the single line string.

[jonhurrell]

Thanks for the feedback. We'll take a look at the above points when we come to our next design iteration cycle. Our next plans for the pattern is an installable (pattern) plugin for the prototype kit to make it easier for designers to implement and test.

[jonhurrell]

@edwardhorsford Have you any insights into the perceived long list of results problem, e.g.: show a long list, or paginate, or use another (not advised) element (select)?

[edwardhorsford]

@jonhurrell so far we've not done anything about the length of results. My previous experience on projects has been that people tend to be more accommodating of very long lists of radios.

For this specifically, by default the OS Places API will return up to 100 results. The vast majority of postcodes for domestic addresses will likely be well under this.

[jonhurrell]

That's the stance we took on initial publication. We are finding there's a barrier to adopt the pattern because of the perceived problem of users have trouble with long lists, despite no one putting forward a better alternative and in most cases using other components (pagination, which caused general findability and navigation issues) or opting to put the list in a select.
Do you have or know of anything further we can speak to around people accommodating long lists?

[edwardhorsford]

@jonhurrell I guess the main mitigation is in offering the 'building or street number' field to optionally filter the addresses.

I can't point to anything specific, but there's been lots of anecdotal reports on cross gov slack over the years about teams being wary of having lots of results but finding in usability testing that in practice it's not an issue.