||HM Courts & Tribunals Service
The service met the Standard because
The team demonstrated that they have focused on delivering a minimum viable product that will improve the divorce application process and generate significant efficiency savings for the business.
The team has demonstrated how it has used customer insight to rapidly iterate the service.
About the service
Service Manager: Adam Lennon
Digital Leader: Matthew Coats
The service met the Standard because the team demonstrated that they have focused on delivering a minimum viable product that will improve the divorce application process and generate significant efficiency savings for the business.The team has demonstrated how it has used customer insight to rapidly iterate the service.
The purpose of the service is to provide an effective and efficient way for individuals to apply for their divorce. This will provide a better service and process that will meet user needs and expectations.
Detail of the assessment
A clear set of user needs were defined during Discovery, through insight gained talking to the different people involved in the service; end users (applicants), court staff and support staff (PSU and CAB).
The end to end service user journey has been mapped out, from applying to get a divorce to receiving a decree absolute.
Alpha research and development has focussed on the initial form that is required to be completed in order to apply for a divorce. This has narrowed the scope of the research to understanding how straightforward (or not) the existing paper form is to complete and how it can be improved in the digital version.
The main driver for this is that 40% of forms submitted, are rejected by clerks due to errors in completing the form.
Two main issues of the existing form were identified as priorities to be addressed during Alpha development: jurisdiction and sharing marriage certificate details.
Research during the Alpha stage has integrated different lines of enquiry; contextual research, usability testing, prototype testing with front-line staff, surveys (call centre and nationwide). In addition, the team spent a day at the Digital Accessibility Centre in Neath, sharing the prototype with people who have different accessibility needs.
A good working relationship has been established with the Personal Support Unit (PSU) and Citizens Advice Bureau (CAB) in the Nottingham area.
In addition, the service team confirmed that they will be working closely with a dedicated Assisted Digital expert, during Beta development.
Research felt like it was at the heart of the work being performed by the service team. This was demonstrated through the way the whole team are involved in the research cycle.
The team has the right mix of skills and expertise but is very dependent on contractors and suppliers. This will likely continue into the future and the team needs to work closely with the wider programme to ensure this doesn’t become a risk to delivery.
The team provided a good overview and design of the system they will build initially for Beta. Given the current scope of the service this design seems appropriate though it is understood that it will change as the service moves away from document generation.
The team have chosen a straightforward tech stack that they should be able to build upon as they approach public Beta. It is recommended that the team consider options to reduce their reliance on the HMCTS Ops Services team for deployment and operations in order to gain greater control over their system.
Within the scope of the current service, the team demonstrated that they perceived there were low risks of fraud within the service as the information is used in a way similar to the current paper process and all submissions require a payment.
We recommend that the team try to adopt an approach where they can open source their software easily and work in the open. Their Frontend service could be a suitable first candidate.
The team are engaged with the GDS design patterns and cross-government design community and the prototype looks good. However it’s hard to describe the service within its current scope as a digital service, as the user is still required to print and post their form - along with their marriage certificate - to the court.
Over the next few months the team will need to design and build the digital submission part of the service, as well as a way to digitally upload a copy of their marriage certificate. They also need to investigate any potential security weaknesses that making this process simpler might introduce, as the current security model is largely based on paper evidence.
The team has established a baseline cost per transaction and will work to create a benchmark for user satisfaction using an exit survey. The service has already registered with the Performance Platform.
To pass the next assessment the service team must:
Show a fuller digital end-to-end service at a beta assessment: Until now the service team has focused on the initial divorce application process. This requires the user to print and post the application to HMCTS. The assessment team recognise that this will deliver benefits in terms of insight into users and efficiency savings in the short term. When the team returns for a beta assessment they should show how the entire service will work.
Show user research demonstrating how the service team aim to reduce the rejection of 17% of applications by the judiciary.
The service team should also:
Consider developing plans (probably with other parts of the HMCTS reform programme) to mitigate their heavy reliance on contractors and suppliers and how they will manage knowledge transfer.
If the above recommendation to show a fuller digital end-to-end service at beta assessment is too onerous, the team should consider splitting the service vision into manageable chunks that could be implemented, and assessed, separately.
Digital Service Standard points