Apply for Probate - Alpha Assessment
The report from the alpha assessment for HMCTS's Apply for probate on 9 December 2016 and the reassessment on 21 February 2017.
| Stage | Alpha |
| Service provider | HM Courts and Tribunals Service |
About the service
Service Manager: Paul Downer
Digital Leader: Matthew Coats
The service will enable personal applicants to apply for a grant of probate in a clear and easy way, giving them the legal right to administer the estate of the person who died.
Results - 9 December 2016
To meet the Standard the service should:
-
Design, test and iterate the end to end journey, including the process from submitting the application to receiving the grant.
-
Map the privacy, security and fraud risks for the private beta and show how these will be mitigated.
-
Make the code available as opensource.
Detail of the assessment - 9 December 2016
Lead Assessor: Milan Bugonovic
User needs
The team showed a strong understanding of the users of the service, and how the service fits into their users’ wider experience of bereavement.
This understanding has come from a good range of user research activities, with a good variety of users, and through organisations like their Personal Support Unit and the Citizens Advice Bureau.
The team has expressed what they’ve learned in a good set of personas and an excellent map of their users’ wider journey, including links to other services.
The panel is impressed with the work the team has done to improve the application process for users, including removing the need to swear an oath in person. That step would be a significant barrier for people with impaired mobility or who have difficulties with verbal communication.
The team are working well to understand and meet the needs of users will lower digital skill and access, including simplifying the paper version of the application form for users who will still need it.
However, the team could not show the panel how the user’s journey continues from submitting their application to getting their grant. And the team could not show any evidence that their design for this part of the service works well for users.
This is a concern as there are significant risks in this part of the journey. For example, if a user does not understand the instructions for sending the original will, there could be a lengthy delay, or the will might be lost or damaged.
Also, the team has done little research with users who experience a disability or who use an assistive technology. This was apparent in some parts of the service. For example, the service does not give users any choice of communication channels: email, voice phone or textphone.
The panel understand that the team cannot do complete accessibility testing on their prototype. The team can however learn about the barriers that disabled people currently face so that they do not replicate those barriers in their new service.
Team
The team is currently comprised of 2 civil servants with the remainder being contractors, with the team aiming to stay the same size in beta. The service must have a plan for a long term sustainable team during beta. The team runs a mix of scrum and kanban, with processes evolving through regular standups and retrospectives.
They have also incorporated user research de-briefs, three amigo sessions and strong sign off approaches. The service team clearly articulated the governance and the relationship that each of the boards and authorities have with the service.
Technology
The team plans to make appropriate use of technology given the intended scope of the service. The team showed a stack optimised for frequent deployment with minimal impact to users.
To ensure that the department is able to continue to operate and iterate on this service it is essential that at least one senior civil servant technologist is brought into the team.
Coding in the open
The team had not opened any code at the time of the assessment and did not have a detailed plan of what would and would not be opened in beta. The process described for open sourcing was one where code is periodically copied and placed in the open, this carries a number of risks:
-
Due to the overhead of the process, the team prioritises other work and does not open much of the codebase.
-
People who wish to re-use the code do not have access to an up to date version with all bugs patched.
-
People are discouraged from contributing to the code because it’s unclear who they can talk to, what the open issues are, whether things are currently being worked on.
To meet this point of the standard at a future assessment, these risks must be mitigated. The service will not pass at beta if the code is not opened.
Security and fraud
The team outlined plans to minimise personal data held at rest, for example by deleting all data from the external-facing system once the form has been submitted. Save and return functionality is still to be worked out in beta - the team will need to ensure that the mechanism adopted is usable while also providing sufficient protection from attackers.
The team described a change to the existing application process which would eliminate the need for the executor to make a face to face “vow”. While this is a welcome improvement to the process, the team did not present a clear view of the fraud risks around the service. The two main risks discussed were:
-
An unauthorised person stealing money from the estate of the deceased using a probate form (genuine and issued to them in error, genuine and issued to someone else or fraudulent).
-
One of the executors excluding the other executors to become the sole person with authority to administer the estate.
The risks need to be analysed collaboratively with the other parties that would be involved such as banks - as the place where the attacker would “cash out” would not be within the service. The panel understands that there are many forums in which the financial sector collaborate and discuss fraud, and would expect the team to be taking an active role within some of these.
Design
The team have created a prototype service broadly in line with the GDS design patterns and done a good job of reducing the complexity of the service. The current paper form is being redesigned based on the service’s user research, and removing the final face to face step of swearing an oath is a significant improvement in the service and is to be commended.
The offline parts of the service must be included and designed as part of the service development. The user need is only fulfilled when the user receives and uses the grant. Users must know what the next step is and be clear of how long the process will take.
Similarly, payment for the service by card online should be a priority for the service.
The service relies on (and is linked to) the Inheritance Tax service. The teams are working together, with an idea of integrating the services, and this must be investigated thoroughly during the private beta. Users need a clear process and should only have to enter information once.
Terminology needs to be consistent through the process, and HMCTS, HMRC and GDS content designers must work together to ensure the content is easily understandable, with proof from user research.
The team has a good connection to groups providing Assisted Digital help to users. However the official help route by phone cannot currently access information from the probate administration system. The team should look at how better support can be provided in the new digital service.
Analytics
The team had a clear idea of the type of analytics and key performance indicators (KPI’s). They have clearly thought about which KPI’s and metrics they need to measure on both the online and offline (such as call centers) sections of the service and have looked at these beyond the mandatory four KPI’s.
Recommendations - 9 December 2016
To pass the reassessment, the service team must:
-
Design, test and iterate the end to end journey, including the process from submitting the application to receiving the grant
-
Map the privacy, security and fraud risks for the private beta and show how these will be mitigated
-
Make the code available as opensource
To pass the next assessment, the service team must:
-
Work together with HMRC Inheritance Tax team to integrate the two services and create a better user journey
-
Research with users who experience a disability or use assistive technologies, to understand the barriers they currently face, and iterate the design of the new service to reduce or remove those barriers
-
Create support and Assisted Digital channels that can help across the IHT and probate journey
-
Create a common glossary between GDS, HMRC and HMCTS and ensure all information and services use this
-
Show how a sustainable team can take the service into public beta and beyond
The service team should also:
-
Integrate online payment
-
Include user research with solicitors and develop areas of the service that better meet their needs
-
Have a data analyst on the team to help understand analytics and gather other forms of service data
Digital Service Standard points - 9 December 2016
Reassessment Results - 21 February 2017
Result: Met
The service met the Standard because:
-
The team were able to show the full end to end journey for users, including what happens when users have submitted their applications.
-
Engagement work has been started with the banking industry to develop more understanding of fraud risks.
-
The team have worked to meet recommendations from their previous alpha assessment, and work is continuing between GDS and HMCTS Reform to open sourcing.
Detail of the assessment - 21 February 2017
Lead Assessor: Milan Bugonovic
Point 1 - Understanding User Needs
The team are now researching and designing the part of the journey after the user has completed the digital application for probate. The internal process is well defined and understood, and the team is iterating the guidance and notifications that users will see.
In addition to having users try the service in private beta, the team can learn more quickly by broadening their research participants for usability, accessibility and comprehension tests to include any likely user of the service.
It is important that the team understands how people use necessary documents during the application journey. Home visits are a good way to test understanding of which documents are needed, whether they are available, how they are used.
Point 7 - Managing data, security level, legal responsibilities, privacy issues and risks
The team articulated the risks surrounding use of the service and explained that the team had made contact with the banking industry in order to develop a holistic understanding of the fraud threat to citizens. This engagement is at an early stage, but that is appropriate for alpha.
Point 8 - Making code available as open source
The team explained that all front and backend code would be open sourced during the beta, with the exception of some code containing secrets and other code that is used to manage and interact with components belonging to other teams within the organisation. At the time of the assessment no code had been open sourced and this point is therefore Not Met at this assessment.
Point 12 - Creating a simple and intuitive service
The team has started work on what the user will see after they have completed the digital application for probate, are including this is user research and will be iterating this.
The internal process for probate has been improved to include a diary, meaning cases will not be lost and users will be prompted to complete the necessary offline steps.
The online statement of truth has been researched and seen to be better for users than a face-to-face oath swearing, whilst remaining an important declaration.
Recommendations - 21 February 2017
To pass the next assessment, the service team must
-
address recommendations from the previous alpha assessment report
-
Iterate the steps after filling in the digital application, using several different research methods including usability and comprehension tests, as well as private beta analytics
-
Design, test and iterate the emails, letters and helpline support for the service
-
Conduct one-to-one research with users with a range of access needs, as well as commissioning a technical accessibility report from DAC and implementing fixes for their findings
-
Build on the engagement with banks and use collaborative techniques to model the fraud threat and thus develop techniques to detect and defend against fraud
-
Open source the frontend and backend code for the service
The service team should also:
-
Continue to research with people who are about to apply, are applying or recently applied for probate, to understand their experience
-
Broaden their user research participants to include anyone how is a likely user of the service, for general usability, accessibility and comprehension testing
-
Use home visits to test understanding of which documents are needed, whether they are available, how they are used through the application journey
-
Seek input from the National Cyber Security Centre on ways of working with industry to minimise fraud