Search for something
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.
How it works
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).
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.
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
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.
More research is needed. If your service uses this pattern, share your user research findings.
Help us improve this pattern
This pattern needs improving. We need evidence about:
- any research findings
- how to highlight search matches
- how to write for this pattern
To contribute, add your thoughts and research findings to our GitHub discussion, or follow our contribute guidance.