Background
When the Apply for QTS in England service was launched, the end-to-end assessment of an application was designed to be completed by an assessor.
Trained administrators (admins) have since been brought into the team and now undertake some of the tasks previously completed by assessors.
Most notably, admins would be taking on ‘verification’ tasks, where information from applicants needs to be verified for an application to progress.
This meant a new user group (admins) for the service’s case management system (CMS), as well as new workflows to accommodate what would become separate workflows.
In addition, some verification tasks took place outside the service, which made it difficult to track progress. Some of these tasks needed to be brought into the service to maximise efficiency.
Purpose of the design work
With this piece of work, we aimed to:
- define the new admin role and tasks
- create new journey flows for each user group (admins and assessors)
- bring some verification tasks into the service
Getting started
Our first step was understanding our new ‘admin’ user group, as well as the tasks they would undertake as part of their verification workflow.
We started by mapping the most complex verification task the admin would undertake - gaining consent if an applicant’s qualifications needed to be verified.
This was also one of the tasks that was being brought into the service as it was currently being carried out via email exchange.
Read more about how we designed the new consent and qualification verification workflow.
We also looked at how the current CMS presented tasks within the assessment process. This led to 2 design updates:
Restructuring the application overview screen
We realised the current structure and statuses on the ‘Application overview’ screen in the CMS was too rigid and wouldn’t offer much of an overview to either admins or assessors.
We decided to restructure the navigation of this screen to reflect the different stages an application would go through.
Amended and adding filters
We also decided to add new filters and amend the existing ones in the CMS. Rather than seeing every available status in an increasingly long list, the reworked filters would reflect who needed to act on a given application – an admin or an assessor.
This allowed each user group to only see the tasks they could work on. It also reduced the list of applications they would see, reducing clutter on the page.
Initial insights
We took our initial designs to the TRA, including assessors and admins. This user research gave us some positive insights:
The simplified filters were appreciated and made the CMS easier to navigate
Assessors were happy to delegate admin tasks when it was clear who should be actioning what
Both assessors and admins were pleased that consent verification would be within the service and would be easier to track
However, one piece of the new consent flow was very confusing for admins. This was when 2 different types of consent document were needed (1 with a signature which required applicant action, and 1 without a signature). We decided to tweak the consent part of the journey due to this, and fully restructure it. Read more about how we did this in consent and qualification verification workflow.
Reframing the work
After our initial considerations and the first round of UR, we realised this was a much larger piece of work than anticipated. As well as the consent and qualification verification workflow, there were 2 other areas that would require verification: letters of professional standing (LoPS), and work history (references).
We decided to split the build and release this work in 3 parts.
- Verification of LoPS
- Verification of work history (references)
- Verification of consent and qualifications
Overarching changes
There were some changes to the CMS that applied to all 3 of the verification workflows.
Statuses
With separate workflows there was a need to refine the current statuses. This would ensure it was clear at each stage what status the overall application was in, drilling down to show statuses at the levels below, including spoke, task, and sub-task levels.
Submit for review
While admins will perform the verification checks, the final decision on whether an applicant will be awarded QTS lies with the assessor.
Admins will not be able to decline an award based on any of the verification tasks. If any anomalies are raised during the verification of qualifications, references, and/or LoPS then the admin must send for review.
At the end of the verification process, admins will have the option to:
- confirm the award of QTS if nothing has been raised that requires review during the verification process
- send for review if one or more anomalies have been raised during the verification process
Verification decision
We decided to add ‘Verification decision’ to the new ‘Verification’ task list.
This is the handover point at which an application goes back to an assessor after all checks have been done. This is also where all items that have been flagged for review are surfaced, allowing them to be submitted at the same time.
We made this decision for simplicity and to streamline the workflow of the two user groups. This way bouncing an application back and forth can be avoided, saving time and mental load as we show an overview of all items that need to be reviewed.
Split of assessor and admin roles
Due to the new user groups, we needed to create handover points. The first handover occurs upon selecting what items need to be verified.
The admin now selects all items they want the admin to verify for an application directly on the service. As per GDS guidelines, we changed the checkbox behaviour for all verification items, so that an assessor has to select what they want to be verified rather than having them pre-selected.
User research showed that assessors needed a place to write comments for verification as some institutions are very specific with their requirements, for example needing a double-sided copy of a transcript. This note would be surfaced in the corresponding admin task.
We also added a summary screen, playing back what the assessor is requesting and giving them the option to change their input.
Finally, there is a success screen, signposting the end of the assessor journey and that the application will now be picked up by an admin.
Verification of LoPS
After following the steps to obtain the LoPS detailed within the service, the admin selects a checkbox indicating the task has been completed. This will update the task status. Once an answer has been received from the relevant competent authority, the admin has to record the response on the service.
Should the response be negative or not received at all, the admin has to submit the LoPS for review where an assessor can make a final decision.
Verification of work history
For the majority of countries on the service, obtaining references is mandatory.
On the assessor side, we changed the behaviour of the list to remove pre-selection. This ensures the assessor only asks to review the most relevant and appropriate references.
Once references have been received into the service, it is now an admin role to review them.
When responses are not ‘positive’ referees have to leave a comment to explain their response. While it’s possible that a response could be negative, but the comment is positive, it was decided that any responses with a comment should be sent for review by an assessor. This will be monitored to see how many references are sent to assessors because they have comments.
