Discovery and Alpha research suggested that users needed the toolkit to afford both linear (following the toolkit steps) and non-linear use (jumping straight to relevant resources). This is because some users may have already identified workload issues or may be revisiting the service.
Our users also don’t have much time, and we wanted to provide a journey to resources for them that was a quick as possible.
To build the design for the non-linear journey that we tested in Alpha, this would require using java script. However, it’s important we keep the codebase of our service as simple as possible, so adding resources in the future is easy and simple for non-developers. And so, in Beta we explored how we could offer this non-linear journey in a simpler way to account for this technical constraint.
Another feasibility issue with the original design was using a ‘search bar’. Whilst many users were keen on this, many had unrealistic expectations of what resources might be available, and we felt like many would not be able to find what they were looking for.
Similarly, whilst we could have used a simple search, we felt having tested search on some other services that it’s not always the quickest way to find what you need. Unless a lot of work is put into it, it often prioritises pages less directly related to what you’re searching for.
What we did
Due to the complexity of building a search bar with filters, we introduced existing GDS components that still allow users to browse through the list of resources across the whole service without the complexity of building filters.
What we found
In usability testing, users were still able to see an overview of all the resources without having to commit to them and could still digest information and surface what they wanted quickly.
What we decided
As a result of our design exploration and user testing, we think this design still offers a quick way for users to assess usefulness of each resource without having to commit to them, whilst also aligning with technical feasibility.