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: Government Digital Service
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:

  1. 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.
  2. 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:

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:

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 Met
Published 13 August 2018