Why we did this work
The routes and professional status data ‘bucket’ was the next group of data we migrated from DQT to the TRS. We needed to design a way for users to add and manage routes and professional statuses in the TRS Console.
What we did
We took an iterative approach where we:
- created an initial concept
- used feedback from UCD colleagues and the wider team to refine the concept
- tested the concept with real users
- ideated on the key findings and prioritised the solutions
- iterated the designs
Once the initial design concept was ‘good enough’ we invited out support staff, admin and inductions colleagues to look at them.
User testing
We wanted to:
- validate that users recognise the link between routes and qualifications and can provide the necessary data
- ensure this journey meets users' needs and aligns with their processes
- confirm that users understand what is required of them and can provide the necessary data
- identify areas for improvement to better serve users' needs
What worked
In general, the concept, journey and interactions were understood by participants.
“I expect to add end date and award date straight after the start date. We usually only hold records for people who have QTS, but we may also have instances where they don’t have it yet.”
There were also issues with presenting the right steps and questions at the right time, and some of the language could have been clearer.
“I would think that ‘provider’ is different from ‘establishment’. I would expect the provider to contact Helpdesk as they are the mediator between the two.”
What didn’t work
In the design we tested, separating route and status did not work because users saw ‘end date’ and ‘award date’ as part of the same journey and expected them to be together.
“I expect to add end date and award date straight after the start date. We usually only hold records for people who have QTS, but we may also have instances where they don’t have it yet.”
There were also issues with presenting the right steps and questions at the right time, and some of the language could have been clearer.
“I would think that ‘provider’ is different from ‘establishment’. I would expect the provider to contact Helpdesk as they are the mediator between the two.”
Improvements based on user testing
To improve clarity and usability, we:
- combined the route and professional status into a single flow
- iterated content to make it clearer what’s happening and what is expected of the user – for example, using ’professional status’ instead of ‘qualification’, or consistent use of ‘provider’ instead of ‘establishment’
- added a ‘Why are you editing this route?’ page for users to enter a reason and upload evidence
- added accessible autocomplete with fuzzy search capability to some pages
- added status tags so users can see if a route is ‘in progress’ or ‘awarded’
- added the ability to edit the route status so that on completing a route the user only needs to enter the award date and induction exemption
- separated the change reason and evidence upload into its own section on the Check your answers page to make it easier to read
Next steps
The designs are currently in build and further testing will be carried out.
Components we used
Accessible auto complete so that a user can quickly find an item in a long list using fuzzy search.
Conditional reveal radio button so that a user can add additional information to a selection they are about to make.
Screenshots
Routes home page showing no route has been added
Select degree type
Select training provider
Change reason and evidence upload
Routes home page
Select degree type
Select training provider
Change reason and evidence upload
Prototype
The prototype can be found here.