Find an address

Design notes

Government services very often need to ask users for an address. There was a clear user benefit to having an effective address entry pattern for DWP, as benefit claims can be delayed if an address is not resolved correctly or can’t be identified.

Addresses are very varied and have surprising characteristics: we found Falsehoods programmers believe about addresses useful for test cases.

When we began developing the Find an address pattern we found that:

most designers began with some variant of a postcode lookup
there was no detailed guidance on how this should work

Design goal

Our stated goal for the pattern was: ‘to quickly find a unique address while not making the user do unnecessary work’. The second part of this was important: it can be tempting to make users do the work of matching an address that we recognise.

Some important constraints were:

The pattern should be flexible enough for use in different address scenarios – for example, when asking for a person's home address or the address of a business
DWP services use an API to access a common address lookup service, so our pattern had to work with the results from that service
It should not require JavaScript to work (though could use it for enhancements)

Context

We researched address lookups in use in DWP, across government and elsewhere. We also looked at patterns in other design systems.

There is an existing GOV.UK Design System pattern which explains when to use multiple text fields, an address lookup or a single text field: however it does not give detailed advice on how to design or build an address lookup.

Address lookups in DWP

There was a range of implementations within DWP. We held a workshop with the DWP design community to learn about existing patterns and work towards a standard.

Some services did not have an address search function and used manual entry with multiple text fields: in this case they followed the GOV.UK pattern, which is also what we recommend.

Some services offer the manual entry option only after users have tried and failed with an address search. Our pattern instead gives this option on every screen.

Other address lookups

Design decisions: search page

Could we use typeahead?

Typeaheads – where the address is looked up as the user types it into the search box – can remove the need for a separate search results page, potentially making the task simpler.

An accessible typeahead could be used with this pattern as a progressive enhancement. However, we need more examples of how they can be built accessibly and for users without JavaScript.

The Office for National Statistics (ONS) has published research on a typeahead address search used for the 2021 Census. When used without JavaScript the typeahead was replaced by a postcode search and list of results.

The Royal Mail postcode finder uses JavaScript to power its typeahead and does not function without it.

We considered the prototype ‘accessible autocomplete’ component developed by the GOV.UK design system team (and since improved by the Department for Education). However it's designed for different use cases where there is a locally stored, relatively short list of possible results: not for a live query against several million UK addresses via an API call (or several calls).

If you have used typeahead we actively encourage you to share what you have learned on the GitHub discussion for this pattern.

Choosing search fields

Many address lookups begin with a single, mandatory postcode field. We wanted our pattern to be usable by people who did not know the postcode of the address they were looking for: we know from research that this is relatively common when the address is not the person's home.

So we included a second search field for the first line of an address. The DWP API supports searching on either field so we were able to make both fields optional (though of course at least one needs something in it).

We decided to put the postcode field first rather than the Building number or name field. This was because:

user research from one service found that if people entered only one field, it was more likely to be the postcode
if a user inputs only one field, they will get better results from postcode alone than from Building number or name alone
it supports the mental model that the building number filters the postcode, rather than the other way around, which is correct
it may help to avoid people entering their full address in the Building number or name field, which has been observed in some services

Postcode: mandatory or optional?

In our example implementation the user must enter something in at least one of the two search fields, but neither is mandatory.

It is common to make the postcode field mandatory, and some services do this in the interest of delivering better search performance. We chose not to do this in our pattern for two reasons:

giving users as much choice as possible over how to enter an address
making the pattern adaptable for services asking for non-residential addresses

Research found that people commonly don't know the postcodes of addresses that aren't their own. In DWP services, for example, they might need to enter the address of an employer, a care home or a GP surgery.

We're also able to do this because the DWP API doesn't require a postcode and allows for searching on address first lines.

‘Address line 1’ or ‘Building number or name’?

Although field labels are something that we expect to change from service to service depending on user needs, we wanted the default labels to be as widely usable as possible. The choice was between ‘Building number or name’ and ‘Address line 1’.

In the preview version of this pattern the field label was ‘Address line 1’, but we reversed this choice in the published pattern because:

the convention of a postcode + house or building name is well established in address searches
although ‘Address line 1’ has been found to work better in some manual address entry forms (with multiple text boxes), especially for business addresses, this isn't necessarily the case for residential addresses
early testing suggested that entering a building number or name produces better search results when used with the DWP Address service API than entering the full first line of address

Design decision: results page

An example graphic on a previous iteration of the GOV.UK address pattern showed matching addresses contained in a dropdown Select component: many services implemented this as a pattern to follow.

However, the GOV.UK Design System guidance recommends against using the Select component except as a last resort, due to known usability and accessibility problems. For this reason we needed an alternative way of presenting search results in a list.

Radios

The remaining clear option was a list of addresses from which the user could select the correct address. The natural choice for a list with mutually exclusive options was a list of radios.

The tradeoff against using a Select component was that a long list of results could be hard to navigate, creating its own usability issues.

Pagination or filtering of long results lists

We decided not to mandate a particular solution for this as the need for it is very dependent on the relevance of the search results coming from the API used. For some teams it may not be a problem at all; for others, if users struggle with long lists of results the pattern can be enhanced with supplementary questions, filtering or other solutions.

In practice a long list of results can be surprisingly easy for users to navigate, especially if the sort order is obvious. It also enables them to use a browser's text search to find the result they are looking for, whereas pagination requires an element of guessing if the result is not on the first page.

Pagination was considered but research showed it tends to raise more problems than it solves. Pagination is particularly unsuited to this kind of search where there is only one correct result and all the others are incorrect: it may be better for a page where users are looking for the ‘best available’ result, such as a general search engine results page.

Next steps

We're particularly interested in these questions:

Can a typeahead be implemented as an enhancement to this basic pattern for users who have JavaScript available?
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?

Get support

Need help implementing this in a prototype or production build? Get support from the Design System team.

Give feedback

We depend on insights from real projects to update and improve the design system. If you use something we made, tell us how it went.

Could we improve this page?

Send questions, comments or suggestions to the DWP Design System team.

Last updated: 1 November 2024

Cookies on the DWP Design System website