Background
For the background to this design work, please read QTS application verification workflow.
Understanding the qualification verification process
Verifying an applicant’s qualifications is the most complex of the new verification tasks that admins would undertake. This is because the process involves several steps:
- Assessing what type of consent, if any, is needed to verify
- Getting written consent from the applicant, if necessary
- Managing return of consent if requested
- Requesting verification via a third party (Ecctis)
- Managing return of the verification
- Assessing the verification and proceeding with the application or sending for review
To understand the process the UCD team mapped out the consent and qualification verification journey alongside product and BA.
Different types of consent
We identified 3 different consent types.
For 2 consent types a ‘wet’ signature is required, which meant we needed to build a flow where applicant action was needed. For the last consent type, no signature was required, and the admin could proceed to the next task without having to wait for an applicant.
Admins would need to go to an external provider (Ecctis) to find out which consent type was needed, then return to the service.
Verification of qualifications
Until the admin selects the consent method needed, only 1 task is displayed in the verification spoke. This is due to the journey branching depending on the consent method needed for each individual qualification.
Up to 2 qualifications can be verified for each application – this is due to a requirement identified during the design stage but can be scaled up in the future, if needed.
Admins have to leave the service to obtain what kind of consent is needed from the Ecctis portal. Upon returning, they select the consent type from a short radio button list. We implemented a summary screen with the option of changing their input. Changing consent type is only possible until documents are either generated or uploaded, allowing for some flexibility.
While our initial design received positive feedback, upon refining it became evident that it could be improved as it proved difficult to keep an overview, especially if two different consent methods were selected.
In the first draft of the qualification flow, all tasks needed to be performed in a rigid order. This was done so admins could see all tasks that could be actioned immediately once they went into the verification spoke, and to mitigate the risk of missing any steps in the process. However, due to the formatting, some of the tasks on the list ended up having multiple steps (for example, ‘Select and send consent document’), making tracking difficult.
The redesign focused on a cleaner overview, despite a potentially lengthy task list. The separation of tasks grouped for each individual qualification matches the mental model of the admins as the tasks are directly associated with the qualification they are actioned for. Additionally, by giving the admin a better overview of all individual tasks, we simultaneously mitigate any risk of tasks being forgotten.
The design of verifying qualifications
Upon opening the verification spoke, the admin will see a single task: Check and select consent method.
After obtaining the consent method needed for each qualification from the Ecctis portal, and confirming their selection, the admin will see a new task list that lists everything they have to do grouped by qualification.
Main difference between consent scenarios
Due to the journey splitting depending on what consent type is needed, we brought all tasks that need to be performed into a separate, nested task list.
If more than 1 qualification needs to be verified, both qualifications can be worked on at the same time and don’t have to be done in the order on the screen.
If written consent needs to be obtained from the applicant, the 2 tasks ‘Upload consent document’, ‘Send consent document to applicant’ and ‘Record applicant response’ are displayed.
If no written consent is needed, the admin generates a consent document on the service. There is a button inside an inset text component in the corresponding task that enables the user to do so, with a tickbox they need to select to update the status on the service.
Once consent has been received from the applicant or generated on the service, the document gets uploaded on the external Ecctis service. The admin has to tick the box on the ‘Request Ecctis verification’ task to update the task status on the service.
If 2 verifications have the same type of consent (such as 2 written or 2 generated documents), the task list shifts so that the task that needs to be performed for both qualifications displays in the ‘All qualifications’ task list. We have done this so that an applicant only receives 1 email if written consent is needed, and likewise only 1 consent document needs to be generated as they are generic.
Recording applicant responses
Once the applicant has returned the signed consent document, it will displayed within the service to be checked by an admin.
It is displayed within an inset text. If the document is returned in PDF format, the admin only gets the option to download the document, but should the file be in any other format, it can be converted on the service. This was a pain point we identified during testing, as admins previously had to do this conversion manually as the Ecctis portal only accepts documents in PDF format.
On this screen, the admin can approve the document if it’s valid or send it for review if there's an issue with it for an assessor to make the final decision.
Overdue items
Should an item go overdue, it will receive an ‘overdue’ status. The admin then has to chase the applicant to remind them. If they still receive no response, they can submit the overdue item for review and an assessor makes the final decision on what to do with the overdue item.
Applicant journey
The applicant journey follows the previously established ‘further information’ (FI) pattern (see Designing the further information journey) but with some changes as we now need the applicant to download and then upload a document.
When the admin submits the consent document to the applicant, they get an email to log into the service. The relevant file gets added to the applicant journey. The applicant can download the relevant document in the corresponding task and needs to tick the box at the bottom of the page to mark the task as complete.
We decided to leave the task open in case the user needs to re-download the document.
Once the task list is completed, the option to submit the consent document will be shown and the user sees a summary screen where they can check their answers before submitting.