Apply for Legal Aid

Adding functionality for client’s with partners

Scroll ↓

Time to read: 8 minutes

Role: Interaction Designer

Tools used: Figma, Miro, GOV.UK Prototyping Kit

Background

The purpose of this project was to scale the Apply service by adding functionality for applicants with a financial partner. A significant portion of users have partners, meaning a joint means assessment was not only a regulatory requirement, but also a policy requirement according to law. Applicants who share a household or relationship need to have their assets and finances assessed together.

The legacy system was the only platform capable of accommodating this joint means assessment.

As part of the project team, I worked with stakeholders, caseworkers, and service designers to build this functionality and ensure compliance with the Legal Aid Agency’s requirements. The new functionality was important for allowing a smoother user journey and enabling the application process for providers.

Goals

- To work closely with dependant services so that we have a consistent user experience.

- To work closely with stakeholders and caseworkers so we still collect the relevant information for the partner as well as the client.

- To create a simple user journey for the providers which doesn't feel too long or complicated.

- To increase the use of Apply by bringing this functionality over from CCMS.

Objective:

Allow applicants with a financial partner to apply

Key result:

Unblocks the roll out to further matter types that depend on this functionality and will encourage engagement in the service for existing matter types

Deliverables:

New flow for partners is designed, user validated, developed and released
CFE changes and means and merits report changes are made

It was important to include work with dependant services as our first goal due to how closely the services were linked. We needed to think about a consistent user experience and how the services worked together.

Tools used

Figma

Miro

GOV.UK Prototyping kit

Creating personas

I created two personas for the users who were expected to provide financial data in an application. The personas helped the team to identify the differences in user goals and needs- this was because only a partner would have to meet certain criteria to be considered a partner by Legal Aid Agency. The partner is also not the same as a main applicant/client, therefore we had to assume they may have less involvement in the process.

User Stories

- As a provider, I want to be able to include my client's partner in the means assessment, so that I can complete a quicker application in Apply and have a more accurate decision.

- As a means caseworker, I want to receive an application with all the relevant client and partner information in a clear format with all the correct evidence attached, so that there is a reduction in RFI's.

How might we’s?

- How might we duplicate the questions for the inclusion of a partner whilst streamlining and simplifying the application?

- How might we simplify the means assessment result page as it gets longer with the addition of partner information?

- How might we account for two different means assessment approaches in the same application (manual bank upload as well as TrueLayer categorisation?

- How might we make the new and longer user journey simple and intuitive for providers?

Kick-off session

I facilitated a session with product managers, delivery managers, lead service and interaction designers and business analysts to discuss the way we work together and improve the process since three services would be working on the same feature at the same time. It was a very productive session.

Analysing existing services

This project was about bringing over functionality from a legacy system which meant we had some structure, however we did not want to duplicate existing issues. I created a miro board to compare our services as they currently stand. I worked closely with the service and interaction designers in the other projects to make sure we were being consistent in our designs and content.

Stakeholder/ business sessions

I facilitated another session with stakeholders and the business side of Legal Aid Agency. This included some caseworkers who could tell us the requirements and what absolutely needed to be considered for the new features.

Iterating the User flow

I created a proposed user flow, taking into account what we knew so far so that when I met with my project team, we would have something tangible to reference. This enabled the team to see just how much the application was going to grow and the possible implications of that.

Updating the User flow

I worked with another interaction designer to create a new and detailed user flow which included all of the existing functionality and the new proposed interactions to include the ability for a client’s partner to be part of their legal aid application.

Project team feedback session

I held a session with the project members which consisted of developers, delivery managers, product managers, business analysts, tests and other designers/researchers. It was a time for us to think about the implications of our current functionality and existing API’s and how adding a new user would affect the service and existing user flow.

Fleshing out the pages

I created a page in figma where I sectioned out parts of the user flow and added potential design patterns using the GOV.UK Design System and MoJ Pattern Library as references.

This was all to make the creation of the user journey easier also so I could show multiple options had been considered.

Creating the user journey

At this point I created the full user journey, referring to commonly used patterns across the service and other related services. Also referring to WCAG and accessibility feedback following a previous DAC audit to ensure the design exploration takes accessibility, usability and inclusion into account.

Playing back the proposed user journey

After many iterations, I held a design critique with members of the three projects where I went over the user journey and encouraged others to comment on the process so far. It was a quick and easy way of getting feedback on the design before prototyping anything using code.

Prototyping in preparation of User testing

I used the prototyping kit to make an interactive experience which we could test with the main user group.

I supported user researchers with the discussion guide and the miro board the notetakers would use during the research sessions. I attended most sessions where I supported the user researchers who led the session, by observing, note-taking, and being available to answer questions about the service a user might have. I then worked with them to analyse the feedback and group them into common themes and insights which would inform the next round of design iterations.

I then went through the specific pages which needed changes- often content tweaks which meant I worked closely with the content designer.

After reviewing the feedback- I went back to Figma to start on the next design iterations. As shown, I separated the Figma file into rounds of iterations to clearly show which stage of the project each design related too.

Thinking about the overall flow and the MVP

I then lead another session with my product team and some members of CCQ (another product team) to look at the overall flow again taking into account the recommendations from Round 1- but to also think about our offering and what the MVP looks like. This is where I really refined the journey and was able to gather insights around technical feasibility and complexity.

Round 2 of User research

Similarly to Round 1, I supported the user researchers with the discussion guide and the creation of the miro board where the notetakers- including myself- would contribute what we have observed and heard during the sessions.

Further Design Iterations based on recommendations

Following on from Round 2 of the user research the User researcher created a recommendation guide to show where I had hit the brief and made positive changes following on from Round 1. There were more recommendations in this round as I had introduced new functionality so there were more iterations to make but we agreed that we had carried out enough user research to stop here.

After the second round of feedback- I went back to Figma to make some updates to components and collaborated closely with the content designer too- using a new page in the Figma file to keep our work clear and transparent.

Updating the prototype

After I had gone through the changes with the team during a design session- I updated the prototype using the Gov.uk Prototyping kit and made sure everything was clearly linked within the prototype and dated for others who want to go through the journey themselves.

I lead a final run-through with our caseworkers and a stakeholder referring to user research and the needs of our users.

There was some push back on the content we changed for the users- but we managed to agree on the majority of the service and the user flows.

The stakeholders were very happy with the work carried out and complimented the session and how I had interpreted the user needs of the work.

Stakeholder run-through session

This project is ongoing and I am currently working with developers as they build the solution.