Apply for Divorce - Alpha Assessment

The report from the alpha assessment for HMCTS's Apply for Divorce service on 25 October 2016.

Stage Alpha
Result Met
Service provider 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

User needs

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

Point Description Result
1 Understanding user needs Met
2 Improving the service based on user research and usability testing Met
3 Having a sustainable, multidisciplinary team in place Met
4 Building using agile, iterative and user-centred methods Met
5 Iterating and improving the service on a frequent basis Met
6 Evaluating tools, systems, and ways of procuring them Met
7 Managing data, security level, legal responsibilities, privacy issues and risks Met
8 Making code available as open source Met
9 Using open standards and common government platforms Met
10 Testing the end-to-end service, and browser and device testing Met
11 Planning for the service being taken temporarily offline Met
12 Creating a simple and intuitive service Met
13 Ensuring consistency with the design and style of GOV.UK Met
14 Encouraging digital take-up Met
15 Using analytics tools to collect and act on performance data Met
16 Defining KPIs and establishing performance benchmarks Met
17 Reporting performance data on the Performance Platform Met
18 Testing the service with the minister responsible for it N/A
Published 18 January 2017