What we know so far
Existing design conventions
Using familiar design conventions contributes to consistency and ease of use. For filters, we think the following conventions can be followed with low risk and should only be changed with good evidence from new user research.
Filters are optional
Applying a filter should not be a required step and users should be able to complete the task without filtering.
There is clear feedback when a filter is applied or changed
For example, if the number of results is displayed this may change when filters are added or removed.
It is obvious when a view has been filtered
The user should not have to remember what they have done to produce the current view. Filter controls such as radio buttons and checkboxes should maintain their state after they are applied, and state information should be shown near filtered results.
Filters can be removed all at once or one by one
It is common practice to have a Clear all function which resets the view to its default unfiltered state so that users can start again.
It is also expected that applying an individual filter is easily reversed, so that users can adjust the filtered view of results and take corrective action: for example, if applying a filter reduces the number of results to zero.
Use radios, not dropdowns
Where users can only select one option from a list of filters, use radios instead of the Select (dropdown) component. There are known usability problems with the Select component (documented in the GOV.UK Design System guidance) and radios are almost always a better solution.
Theories to test
We think there is good evidence for these design choices, but there are also reasonable alternative approaches. We want more evidence to either strengthen or weaken these theories.
Filter controls should be placed on the left
On a desktop viewport, users generally expect to find filters on the left with the list of results to the right.
Batch filtering is preferable to live filtering
Based on our research we believe batch filtering is generally preferable to live filtering, as the expected performance and usability benefits will generally outweigh the additional step of needing to apply filters.
Filters should be visible by default
If there is a long list of filters, showing filter values by default is preferable to hiding them behind accordions or other show/hide elements.
This means users do not have to click into categories to understand what’s inside, or remember where they found a filter they want to use.
Adding more filters should reduce the number of results
If more than one filter is applied – for example Date and Payment status – the system should show only those results that match both filters. That is, it should use AND logic not OR logic by default. Filtering on more criteria should never increase the number of results, only decrease it or leave it unchanged.
The opposite might apply when choosing which values to filter on. For example, checking both Paid and Missed boxes in a Payment status filter would naturally include more records than only checking Paid.
Radio filters should include an "Any" option
If all filters are clearable and some filter categories use radio buttons, users will need a way to unselect a radio button so that nothing is selected. Standard implementation of the GOV.UK radio button component would be to use an additional radio labelled (for example) ‘None of the above’ or ‘Any’.
What next?
If you're working on filters or would like to share work you've already done, please email us.
Could we improve this page?
Send questions, comments or suggestions to the DWP Design System team.
Last updated: