Interaction Designer: Steve O'Connor
Why are search and filters needed?
We had a requirement to include search and filter functionalities as the tables of tasks and services became longer and more complex in the Task and Service Index.
At the time of writing, there are no components for search or filter in the GDS Design System, although they both appear in the backlog. The DfE Header does include a site-wide search, but we wanted a version that searches the tabulated data only.
When other projects in DfE have needed filters, they tend to use the filter component from the Ministry of Justice design system. For examples, see the sites for teaching vacancies and regulated professions. We took this as a good starting point for our requirements.
Making it work for us
By default, the filter component occupies one-third of the total content width of the page and is always visible. Our table has multiple columns and makes full use of the page width. Compressing the table width would cause usability and readability issues or require us to remove columns. Additionally, we cannot have filters stacked above or below the table permanently visible, as this would also lead to usability issues and frustration.
We decided to implement a search bar above the table and use a button to show or hide a selection of filters. This approach keeps the primary focus on the table while allowing quick access to search and filters.
For the MVP, we limited the search to the task names. This allowed us to be specific in the field label and kept the initial search easy to build for the dev team. User research will inform us about user feedback, although the initial "superusers" (the policy team) are part of the product team and were happy with the design.
Filters are accessed with a secondary button named "Show filters," which changes to a yellow-highlighted "Hide filters" when the filters are visible. The highlight brings attention to the change in function.
Filter implementation
The selection of filters was discussed with the product leads and the policy team. We have four checkbox lists and a single autocomplete select for the services. The list of services is over 200 strong, so this was the most accessible option. An "Apply filters" button ensures there is no perceived delay in selecting more than one filter and reduces the number of server calls.
We decided to condense the filter header and the "selected filters" section into one. This takes up less space on the screen when filters are applied, and it was felt that two separate titles were not needed.
Applied filters become chips in the title bar, and a "Clear filters" option is added. Search terms and filters can be removed individually or all at once.
Conclusion
The final search and filter functionalities are still accessible, but the changes made ensure that they are usable in this particular service.