Background
The Legal Aid Agency (LAA) within the UK Ministry of Justice is responsible for funding legal services to help people deal with their legal problems.
The services provided by the agency are heavily dependent on legacy technologies. One of them is an Oracle proprietary software called CCMS – Client and Cost Management System. CCMS supports the submission and the processing of legal aid applications and the payment of providers such as solicitors and barristers.
Over the last year great effort has been deployed to move away from CCMS. By following the strangler fig pattern the plan is to gradually replace specific pieces of functionality with new applications and services.
Task
A team has been looking at a digital service that allows legal professionals to apply for legal aid on behalf of their clients. However, little was done on the processing side of the journey – when caseworkers assess applications and decide if applicants can get legal aid. A new product team was spun up to work on this with the aim of accelerating the departure from CCMS.
A flavour of CCMS’ user interface: “It’s time consuming filling in all the appropriate tasks when making a decision. CCMS is quite unintuitive to use and it can be quite hard to find stuff”
My role and approach
I joined the team at the end of Discovery. I worked on it for 6 months, until we reached Beta.
Part 1: Discovery
During the Discovery phase, I worked with a user researcher and a product manager to:
Map out the as-is journey to identify where policy and tech dependencies lie
Bring our understanding of the service into one canvas and align it with research findings, pain points and insights from subject matter experts
Highlight opportunities to improve processing applications but also for other parts of the journey and other products used by caseworkers and legal professionals
Draft service requirements
As-is journey map: user steps and touchpoints at the top, observations in yellow stickies and pain points in red ones
Indication of where this new product sits in the end to end journey of getting legal aid
User goals for each step of the journey and tasks they need to perform
I quickly realised that a lot was already known about the issues in this space and that there were some clear indications of what could be done to improve the experience for caseworkers and legal professionals.
So, I suggested we draft some design assumptions and start testing them. These assumptions were related to supporting processes and user interface. For example:
If caseworkers have an easier to use service to assess legal aid applications, then they can spend less time retrieving the information they need or duplicating effort and can focus on assessing applications
Sketches of what a new product could look like based on a single case page
Alternative user flow whereby users would go see ‘one thing per page’
Part 2: Alpha
Throughout the Alpha stage, my role was mainly focused on exploring the viability of a product that could replace a part of the end-to-end journey of getting legal aid: decide if an applicant is eligible. So I continue to develop on my initial concepts. Below are some examples of the iterations I have done to the interface to respond to user needs identified during prototype testing.
Evolution of open applications page through three rounds of iteration
Introducing secondary navigation to address concerns that the case page could become overwhelmingly long
We repeated the process of design, test and iterate four times. We did that to explore any gaps in the team’s understanding and to increase our confidence in the proposed solution.
Design process: We went from drafting hypotheses from the back of research to a high fidelity prototype that would accelerate the build of the product.
The prototype helped the team to decide the MVP scope and draft a roadmap for Beta.
MVP functionality: features in scope are highlighted and those out of scope are greyed out
In this phase of the project I have also:
Supported user research on identifying user groups, their needs and pain points
Liaised with colleagues from Assurance to collect and design around GDPR requirements
Worked with the team to agree on an MVP scope that balances the needs of users and the business as well as tech constraints
Created prototypes on Figma based on new and existing patterns from the GOV.UK Design System and independently iterated it based on user feedback
Carried out design critiques with my team and the wider MOJ digital community
Collaborated on the analysis of findings after prototype testing sessions
Worked with developers to define the best prototyping technique for Beta
Presented with the team and passed at a service assessment
Sneak peek of the interface I designed with patterns and components from the GOV.UK Design System
Result
One of the goals of this work was to provide a better experience to users. In 6 months from Discovery to Beta, we:
Increased ease of use from 3.19 to 4.36 out of a 5-point scale
Increased user satisfaction from 2.57 to 4.43 out of a 5-point scale
Decreased the time taken to process applications from 54 to 35 minutes per case