Request a standard or enhanced DBS check
The report for the Request a Standard or Enhanced DBS check alpha reassessment on 14/06/2023
Service Standard assessment report
Request a standard or enhanced DBS check
| From: | CDDO |
| Assessment date: | 14/06/2023 |
| Stage: | Alpha re-assessment |
| Result: | Met |
| Service provider: | Disclosure and Barring Service |
Previous assessment reports
- Alpha assessment for “Request a Standard or Enhanced DBS Check” dated 27/04/2022.
- Initial re-assessment 17/10/2022.
Service description
Request a Standard or Enhanced DBS check allows Registered Bodies (registered organisations legally entitled to request the required level of disclosure check) to request a criminal record disclosure check. The service allows Registered Bodies to fill out basic details and trigger a request to the applicant to complete the required answers. The service then enables the applicant to complete the information and send it back to the Registered Body, where they can carry out the necessary out of service ID checks, before finally submitting the completed application to DBS via the service.
Service users
This service is for:
- countersignatories who work within Registered Bodies. They are registered with the DBS to countersign applications. They make sure that the position is eligible for the level of DBS check requested.
- applicants who need a standard or enhanced DBS check for their role. They use the service to complete an online application form and to access their result
- ID Checkers who meet with the applicant in person or via video call to verify their ID documents and cross-check the application. The ID Checker may be part of the RB, or the applicant’s employer. They may also be the countersignatory.
There are also indirect users:
- employers who request a standard or enhanced DBS check for an employee or volunteer via a Registered Body. They will use the result of the DBS check to make recruitment decisions that ensure they safeguard children and adults.
- DBS staff who process DBS check applications and manage Registered Body and countersignatory user accounts.
2. Solve a whole problem for users
Decision
The service met point 2 of the Standard.
What the team has done well
The panel was impressed that:
- the team have thought about the end-to-end journey for Registered Bodies, including looking at quantitative data.
- it was good that the team framed the session with some pain points that impact some of the wider service – specifically the time to fill in an application and submit it to DBS, which is something the team can improve with their product.
- it was really good to see two teams (so requesting a check and then getting online results) and how their work fits together to benefit users.
-
the team have started to explore how to improve updates / notifications on the status of an application. They have a clear way forward, and areas to test in beta.
- the team has digitised much of the existing process, the benefits of which have been clearly articulated to the panel, and include a quicker end-to-end process, less errors inputting data and illegibility, fewer data security concerns, and giving users with access needs a greater ability to complete the service.
- the digital solution will give help desk phone handlers access to increased levels of detail which will enable them to help users who need to use this assisted digital channel.
- applicants will now receive notifications via email, allowing the service to respond to potential user uncertainty. This has also been validated by quantitative user research.
- countersignatories will be able to check the status of applications and be notified when the result is available.
- the team could now clearly demonstrate how the application part of the service would work, from the initial information being input to the ID checker and applicant interactions.
What the team needs to explore
Before the next assessment, the team needs to:
- we would recommend talking to other teams, like HMPO, about the work they’ve done on keeping users informed about the progress of an application. That should include how to communicate with users who do have extended delays – we know this can be a concern in DBS (albeit not caused by DBS), but we don’t know how common that is for HMPO. We can find a contact if that would help.
-
for the beta, it would be good to see a journey map that covers the whole journey – this might start from the employer making a job offer in a relevant role, through to the individual starting work (these may not be the right start and end points, as that will depend on research, but starting with something that triggers the request for a check). That should help articulate both the pain points – and what the team can realistically address, as there will be areas not in the team’s control and those which would not be sensible to address in an MVP alongside so many other changes.
- explore through research how updates sent by the service can then be passed down from umbrella companies to employers and whether this is sufficient information.
- explore testing and demonstrating one journey from the point of view of a single user and following it from initial job application to completed check. It would be helpful to see internal ownership at each stage of the interaction, and metrics that could help to demonstrate success at each point.
What the team needs to explore
Before the next assessment, the team needs to:
- ensure that more complex interactions and components, such as the search functionality and “checklist”, work for all users and are shared with the Home Office and wider gov design system teams.
- consider the content in the dashboard’s data table. The column names don’t match the data held in the cells. This could be confusing to screen reader users and, in fact, all users.
This, and other content and interaction design observations, have been collected into a “Design Review” document.
5. Make sure everyone can use the service
Decision
The service met point 5 of the Standard.
What the team has done well
The panel was impressed that:
- the team have reconsidered the use of PDFs for ID checking. It was great to see that the rationale for this was tied back to the outcomes and user needs for the service as a whole, and not just the specific accessibility concerns.
- the team demonstrated an agile approach in learning about how ID checkers work and iterating their proposed solution to meet their needs. The team are now very clear about where they have confidence in the proposed solution and the areas they need to test further.
- the team have also tested with Registered Bodies with access needs and identified changes and some areas for future research.
- the team have also thought about ensuring that users who need support to go online can complete the process – and this might be one group of users (the potential employees) rather than Registered Bodies or ID checkers. It was great to hear that the team plan to test this model in the beta.
- the team have undertaken accessibility testing for the RB-facing element of the service. This has been limited to a small number of users, but the findings have given the team good insight to build on, especially around components on the “dashboard”.
- utilising GOV.UK components, patterns and principles, such as Check answers and “one thing per page” have helped the team to design a more accessible service.
What the team needs to explore
Before the next assessment, the team needs to:
- continue to carry out accessibility testing. This includes ID checkers – we understand that the initial research with them was to find out how they work, so this is part of the next steps. It should regularly take place with proxy users if need be.
- continue to test the rest of the journey with users with access needs, including employees, Registered Bodies and Umbrella bodies. We have made comments elsewhere on design patterns – some of those, like sorting and filtering lists of users, may need particular attention.
- as planned, test the user journey for users with Assisted Digital (or digital inclusion) needs. We would recommend bringing a journey map along to the beta assessment, showing how the different moving parts fit together (eg if we encourage all Registered Bodies to use digital by default, how does that impact an individual job applicant who might not be able to go online).
- undertake accessibility testing for the ID-check element of the service, this was a recommendation from the previous reassessment, so must be committed to and undertaken as soon as possible.
- ensure that the team continue to iterate and research the problem areas highlighted by testing with users with access needs. Those primarily being the “dashboard” filters, status tags and the usage and positioning of the action buttons.
- link in with the Home Office Design System, making use of critiques and patterns to improve and iterate the pages that are being used as part of the service.