Apply for legal aid alpha assessment
The report from the alpha assessment for Legal Aid Agency apply for legal aid service on 25 June 2018.
| From: | Central Digital and Data Office |
| Assessment date: | 25th June 2018 |
| Stage: | Alpha |
| Result: | Met |
| Service provider: | Legal Aid Agency |
The service met the Standard because:
- The team showed a good understanding of the wider user journey, and have designed their service to fit into it
- The panel feel that the team have demonstrated that the use of data from Open Banking APIs may be viable. The team should be commended for being the first government service to do this integration and they should be sharing what they learn with other services
- The architecture proposed is scalable and takes advantage of both a departmental platform for hosting and GOV.UK Notify
About the service
Description
The service enables citizens and their solicitors to submit means and capital information, with supporting evidence, and solicitors to submit merit information.
Service users
Solicitors who are contracted by the LAA to supply Legal Aid funded help and advice
Citizens wanting to make a financial declaration to support an application for Legal Aid.
User needs
The team has done a lot of user research in labs to test with professional users and their clients. This testing helped the team to come up with a list of user needs concerning both types of user groups. The team has also discussed information requirements with caseworkers who will be receiving data from solicitors once clients complete their assessments. So far user research work didn’t show any major problems that the service may experience. It was good to see that the team obtained and analysed data on previous usage of this service in order to identify most common users.
The team has not done any user research with users with low digital literacy skills and accessibility needs. Given that these groups are likely to use this service, it’s crucial that the team involves people with low digital literacy and accessibility needs. It is understandable that it may be hard to involve these kind of users if they are currently going through legal processes but this will be a decisive point if this service can pass the next assessment. It is good to see that the team is already thinking about ways to involve professionals with accessibility needs.
In the beta assessment the team will need to explain in more detail what happens to users who don’t have NI number or/and bank accounts. If there is a significant amount of such users, then this service may become problematic. For example, in the UK there may be 1.5 million people without bank accounts but we don’t know how many of these kind of users may need to use this service.
For the next assessment the team will also need to show how they tested with users who use mobile phones and tablets. We know that around 50% of all users on GOV.UK use mobile phones to access various content.
It will be crucial to involve users who will be using their own data with the tool and not dummy data like in previous assessments. This will demonstrate whether users have any privacy and security concerns. Perhaps testing outside the lab will also add more rigour to insights collected by letting users to be in their environment.
The team will also need to explore whether many first-time users need support completing these assessments and how much time solicitors require to provide to assist their clients.
The team should ensure that the research plan in beta covers the testing of the prototype with solicitors. It would beneficial for the to understand how this works in the context of the whole user journey, and to use this understanding to help to iterate the service.
Team
The assessors are satisfied that the team is resourced for current phase and sufficiently evidenced that they are working in an agile way.
The service team clearly articulated the governance and the relationship that each of the boards and authorities have with the service.
The team is currently working in an agile way and evidenced the methods that are used throughout. There is a good approach in place for knowledge transfer and a clear plan for resource in the next phase.
Technology
The team has been working in the open in alpha and intends to continue this in beta. The architecture proposed is scalable and takes advantage of both a public cloud based departmental platform for hosting and GOV.UK Notify.
There are two concerns from a privacy and data security standpoint that should be explored and worked on as appropriate during private beta, and discussed at the next assessment:
- It was unclear at assessment how much information about the origin of the open banking request the aggregator service and the bank itself receives or can infer, and what they are allowed to do with that information. It is important that the citizen is not adversely affected by making an application, e.g. by means of a bank withdrawing credit due to a presumption that its customer is involved in litigation.
- The service team intends to use an existing system that provides role based access to provider staff as an authentication mechanism for the provider part of the service. As the existing system would have been designed with different needs in mind, the service team needs to ensure that this system, as it is used today in the real world, provides sufficient protection for the personal data that will be held in the service.
The service is reliant on multiple APIs provided by other government departments and banks, and at any one time one or more of these may be down or experiencing issues. The team will need to consider how to design and operate the service so that problems are detected swiftly and so that impact on users is minimised.
In order to iterate on the service the team will need a full knowledge of what’s going wrong and where. In order to identify investigate cases where the DWP and HMRC APIs are not returning the expected results the team may need to work out how to get information to a human who can investigate, while still protecting personal information. Teething problems are likely so it’s important that the team has enough information to debug.
The service is using a legacy casework system, progress towards replacing it should be discussed at the next assessment.
In a slightly wider context, the team mentioned that some information, for example scans of share certificates, is required because it is set out in legislation, rather than because it is useful as a means of determining eligibility or preventing fraud. Learning and insight the team develop in this area should be shared with MoJ stakeholders to inform improvement in future legislation.
Design
The team have designed a usable and intuitive service for members of the public who need to prove their eligibility for legal aid. The service is intended to replace the process of annotating and scanning paper bank statements with the help of a legal professional.
The team showed a good understanding of the wider user journey, and have designed their service to fit into it. They have also shown the ability to iterate the design of the service where it didn’t work digitally, for example allowing members of the public to complete the transaction in their own time, rather than in the presence of their legal professional.
The new service will only be for users who already use online banking. This, by nature excludes a sizable number of people, but the panel feel that this is an acceptable trade off because:
- it has the potential to make proving eligibility a lot simpler for users who already use online banking
- assisted digital support (provided by a solicitor) is in place already (it’s the only way to access the service at the moment)
- attempting to make this a digital service for users who don’t have online banking would likely result in something less usable than the current, assisted digital, route
The hardest part of the service to design for is the integration with Open Banking. The team acknowledge their riskiest assumption is that users will trust the service with their banking transactions. They have done the right thing by focusing their efforts on validating this assumption in alpha. The panel feel that the team have demonstrated that the use of data from Open Banking APIs may be viable. The team should be commended for being the first government service to do this integration and they should be sharing what they learn with other services.
In beta the team will see users more concerned about trust and consent when:
- using their real bank account details
- interacting with the multiple touchpoints of the service (solicitor’s office, email, digital transaction) over a period of time and outside the context of a usability lab
They should continue to iterate the design of the service as they learn about these concerns. Already the panel feel that the design doesn’t make it clear enough who is being given access to the data. There are 7 actors in the process (the user, the user’s solicitor, Legal Aid Agency, Department for Work and Pensions, HM Revenue and Customs, GOV.UK and the third party Open Banking API aggregator). The service is too reliant on using words like ‘us’, ‘you’ or ‘we’ where it’s not clear to whom they refer. This goes against the GOV.UK style guide. When sharing data it needs to be clear who, specifically, will have access to which data, for example: ‘Do you agree to share your bank transactions with the Legal Aid Agency?’
Otherwise the service is broadly consistent with GOV.UK. There are some minor points of style, covered in the separate design report. This is fine at an alpha stage; for a beta service we’d expect a higher level of refinement and attention to detail.
In beta the team will also be expected to spend more attention on the wider service. Firstly the screens where legal professionals enter information about the ‘merit’ of the applicant should be revisited. While there are legislative constraints here it may be possible to remove, clarify or infer some questions. Secondly the team must show the complete user journey, including how all kinds of users move in and out of the service (for example where the links into the service are, what the emails that members of the public receive look like).
The team confirmed that would be exploring whether they can expand the service to a wider group of users. It is important for the service to consider how they could take advantage of the HMRC and DWP APIs for users who don’t have online banking, as an example. The panel would like an update on this at the next assessment.
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 the service and have looked at these beyond the mandatory four KPI’s.
The team will need to register with the Performance Platform. The team should establish early on, what data can be collected from the system and shared publicly, so this can be factored in to the iterations.
Recommendations
To pass the next assessment, the service team must:
- conduct user research with people with low digital literacy and with accessibility needs
- conduct usability testing and user research outside of the lab and ideally with users who can then use their own data to help provide more robust feedback
- identify and provide metrics to be shared publicly on GOV.UK’s performance platform
- test the complete user journey with a range of users
- test the service with mobile phone and tablet users
The service team should also:
- continue to iterate the service based on the feedback from users, in particular, from the using their own bank details and how the service interacts across multiple touchpoints
- ensure that content is clear for the user and ensure that content adheres to the GOV.UK style guide
- explore whether the service could be expanded to a wider user group
- test the prototype with solicitors in the context of the end to end user journey and use this to help iterate the service
- explore and explain the user journey for people without NI numbers and/or bank accounts
- clarify how much information about the origin of the open banking request the aggregator service and the bank itself receives or can infer, and what they are allowed to do with that information.
- the team intends to use an existing system that provides role based access to provider staff as an authentication mechanism for the provider part of the service. The service team needs to ensure that this system provides sufficient protection for the personal data that will be held in the service.
Next Steps
You should follow the recommendations made in this report before arranging your next assessment.
To get your service ready to launch on GOV.UK you need to:
- get a GOV.UK service domain name
- work with the GOV.UK content team on any changes required to GOV.UK content
Before arranging your next assessment you’ll need to follow the recommendations made in this report.
Get advice and guidance
The team can get advice and guidance on the next stage of development by:
- searching the Government Service Design Manual
- asking the cross-government slack community
- contacting the Service Assessment team