Filters
Filters reduce a large number of items to just the ones that are most relevant to the user’s task.
Filters are made up of key criteria that users want the results to have. For example, if a user needs to review missed payments they can set a Payment status filter to return only those records with a value of Missed.
Context
Filters are part of the wider concept of refining a list of results. This also includes sorting, text search and pagination, and filters will often be used in conjunction with one or more of these. However, the scope of our work focuses only on filters and not on any of these other tools.
Within DWP, filters are most often used in agent-facing services rather than customer-facing services.
What already exists?
We know about the following things in other design systems:
The Filter component in the Ministry of Justice Design System is a common starting point for DWP teams.
Is a new thing needed?
Teams are creating their own filters from scratch which suggests that some guidance or awareness is needed in order to avoid inconsistencies in use, behaviour and appearance.
The Ministry of Justice component doesn’t include guidance on how clearing filters should work.
Some user research suggests that hiding filters behind accordions as in the MoJ component is not optimal.
The future of the MoJ component is uncertain, as it is marked ‘for review’.
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.
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, follow Welcome to GOV.UK Design System guidance to use radios instead of the Select (dropdown) component. There are known usability problems with this component 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 expect to find filter controls in a left hand column with the list of results to the right.
We have seen desktop examples of filters taking position in a left column or above the results. Most examples have shown filters to the left column. Examples where filters have been shown above the results don’t scale well, and the organisation of the content within the filter becomes less easy to follow as the width of the screen is used to create multiple columns of filters.
It has been noted that on mobile and tablet views filters would inevitably sit above the results and the results would be most likely end up being out of view. We've not seen enough examples of filters above the content or any other layouts that have been widely used.
An internal service tested filters in the right column to determine any preference or performance difference. They found that all users asked (including screen reader users) preferred the filters in the left column.
Batch filtering is preferable to live filtering
With batch filtering, filters are not applied until the user takes a deliberate action such as clicking an Update button. The results list remains unchanged as the user adds and removes filters and then updates when the user is ready to apply them.
With live filtering, the results list updates automatically as each filter is set. This means the results appear to be instant (depending on performance) and filters and results are always synchronised.
Based on our research we believe batch filtering is preferable to live filtering.
Points to note about batch filtering:
- during the process of selecting filters the results shown are not reflective of the options selected until the user applies the filter – so the views are not synchronised
- the user has to remember to apply the filters
Points to note about live filtering:
- unintentional clicks lead to changing the results and any filter related messaging/content
- can be frustrating if multiple filters are applied as results will refresh as each option is selected
- when results are visible (for example on desktop view), applying multiple filters can be distracting and affect the cognitive process as results change on every selection
- when the results are not visible (for example on mobile) the action of filtering being applied is not prominent
- when used at scale there is a performance cost to making multiple requests in quick succession
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.
There is a need for radio buttons to be cleared
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?
Options for future development are:
- use the MoJ component and extend the guidance to include advice on how clearing filters should work, feeding back findings to MoJ Design system team
- provide guidance on how to build an alternative to the MoJ component
- build a DWP component that we think works better
If you're working on filters or would like to share work you've already done, please email us or add to the GitHub issue for this topic.
Could we improve this page?
Send questions, comments or suggestions to the DWP Design System team.