Help users toSearch for something

Also known as: search

Searching for records in a system.

When to use this pattern

Use this pattern to help users find a person, task, place or another type of record in your system, when navigation alone is not a practical option.

When not to use this pattern

Do not use this pattern if users only have a simple list to manage. Try and instead allow filtering, or make automatic suggestions and test this with your users.

Make sure you understand who your users are and what they are trying to achieve before coming up with any design solutions.

Narrow search

If your users normally have a single key piece of information to hand to search with, such as a reference number or identifier, allow them to search by that as it will allow for a quick match. When an exact match is found, surface the match result on the screen (rather than going directing to the record).

An example of a service allowing search with narrow parameters

Wide search

Users may not have a lot of information to hand before starting their search. If this is the case, you should make your search parameters quite wide. For example, if a user is searching for a person, allow them to enter both name and DOB, as well as address and postcode. If this brings up too many results, allow filtering.

An example of a service allowing search with wide parameters

Your users may have different needs, for example:

  • analysts: need a range of search options presented in order to obtain different data types. May also need to add their own search parameters (you should research what these are)
  • caseworkers: need context-specific options in order to find the right results

When presenting multiple options, ensure all entries that are not required are marked as part of the label as (optional).

Speak with technical members of your team to understand constraints in relation to your database, for instance:

  • what users can search for
  • how the data that is brought back will be presented
  • how many potential results may be brought back
  • response time between searching and the time it will take to surface the results

Research on this pattern

Multiple Home Office services use search. If you have evidence this also works for your users, you can contribute to our backlog

Accessibility

It must be possible for someone using a keyboard to complete all tasks in a service. See the keyboard guidance for more information.

All form fields have an associated visible label. Where this isn’t possible a non-visible label must be present. See the forms guidance for more information.

You should make sure

  • when presenting data in tables, that this is marked up correctly
  • colour is not used as the only way to assign meaning to results
  • users can resize text up to 200% and scale up to 400% (tables excluded)
  • users can change font spacing. All of these especially important if there is a lot of data
  • users can turn off, adjust or extend timeouts
  • you do not change results based on filter checkbox selection alone (for example you could provide a submit button)
  • if the search generates errors, that screen reader users know what happened and how to fix it

If your service uses this pattern, let us know of any insights you have on accessibility considerations.

Get in touch

If you've got a question or suggestion share it on the Slack channel #ho-design-system, on GitHub or email design@digital.homeoffice.gov.uk.