UX and Service Design
HMCTS (Her Majesty's Courts and Tribunals Service). Part of MOJ (Ministry of Justice)
The Immigration and Asylum Tribunal allows people to appeal immigration and asylum decisions made by the Home Office. Currently, the majority of appellants lodge their appeal using paper forms submitted by post or fax, with internal staff using an outdated case management system as well as many manual processes.
This project is part a £1bn investment by the UK government to reform Her Majesty's Court and Tribunal Service’s. The aim is to bring new technology and modern ways of working to the way justice is administered.
The digital transformation of this project involved both optimising it for digital delivery and building the digital platform on which to provide the service.
To transform the end-to-end immigration and Asylum tribunal service using digital service layers and modern ways of working.
I was part of the team during the whole agile delivery lifecycle from initial Discovery, to the Alpha and beta phases of the project. In the discovery phase the consultant team was made up of service and UX designers, user researchers, business analysts, a delivery manager as well as a product owner and product manager from the business. Moving into the Alpha and beta phases the team scaled, introducing technical leads and developers, where we incorporated agile ways of working. This allowed us to translate our insights and service design into the delivery of the service.
We initially conducted interviews with exiting users of the service, subject matter experts and stakeholders to develop an understanding of our users needs and the ‘as is’ process.
Research participant breakdown
Before a user research session with a Legal representative
User research session with a tribunal case worker
We then developed a service blueprint map to highlight the touchpoint and identify the key pain-points that needed to be addressed. This also help us to identify the remaining knowledge gaps where we needed to undertake further research.
Immigration and Asylum (as is) service blueprint
Through the discovery we identified that the service needed to cater for several different appeal types, which offered up a number of differences in each of their processes.
That being said, as a team and with with the backing of our main stakeholders we decided to focus on one aspect, “Asylum appeals”. We develop a thin end-to-end MVP for this appeal type, with the aim of then later incorporating the other appeal types into the process.
This allowed us to follow the typical Agile service design framework, starting small, testing, failing, learning, iterating then scaling at the right time.
The next section of this case study is based around the Alpha and beta stages where we designed, developed and built the MVP (Asylum appeals).
Once we built the MVP we moved back into the Discovery/Alpha phase and ran co-design workshops to understand how the other appeal types would work. To view more see moving past the MVP.
Moving into Alpha phase we started to developed a future service map. We held regularly sessions with internal stakeholders, current and future users of the service, where we got feedback and evolved our thinking of what the future service design process could look like.
During our discovery period we identified that a number of appeals that end up in a hearing should have never been refused in the first place.
This insight gave us the idea when re-designing the future process to introduce a step at the start of the appeals process for the respondent (Home Office) to conduct a review. In this review the respondent (Home office) have the opportunity to withdraw if they feel they made the wrong decision.
So far we have had 4 withdraws within only 1 month since launching the new service. Our key stakeholders see this as a remarkable transformation and it has resulted in a simpler, faster experience for Appellants using the service, who are going through an extremely difficult and daunting period in their lives.
A challenge when developing the future service was aligning the HMCTS and Home Office’s needs. Both exiting processes and systems differed considerably and therefore it required both sides involvement to reach an agreement over the future vision.
We engaged with all parties early on in the Alpha phase and facilitated a number of workshops with representatives from each party present to understand each of their needs and expectations of the new service.
One of the workshops we held was to bottom out the scope of the proposed MVP service design.
We considered both internal (HMCTS stakeholder and judiciary) needs and external (Home office, Appellant and legal representative) needs, including the reform programmes common component and home office dependencies.
This allowed us to understand at a high level what bespoke technology we would need to build and what we could reuse (common components) that was already being built by other jurisdiction with a similar need across the reform.
One key achievement at this workshop was that we managed to achieve alignment with home office over the integration points of each of our services. This meant we could achieve a seamless end-end process removing potential barriers between a number of key touch-points.
V2 of the service process (with actions and questions) after co-design workshop with stakeholders and users
Final MVP service Process
Once we had a solid understand of what we wanted the future Asylum appeals service process to be, we started to identify the key journeys and develop some higher fidelity designs.
We did several rounds of usability testing which allowed us to evolve the general flow and content of the journeys
One of the main journeys of the appeals process is the initial appeal application that is completed by a Legal representative. We stated with the existing paper appeal application refining the information, content and data through stakeholder and user research sessions and iterated the flow several times. We managed to strip the appeal application down from 127 fields to 29 fields resulting in a simpler and quicker experience for a legal representative to complete and submit their appeal.
In order to enable lean case progression online, that may resolve an appeal without the need for a hearing, a legal representatives is asked to submit the appellant’s appeal (Skeleton) argument, for it be reviewed by the respondent (Home Office) and the Judiciary.
Below are the three options we explored.
This meant both parties would have multiple rounds of trying to agree on the issues of the case.
This process lead with the judiciary, who would engage with each party individually to reach an agreement on the issues.
3. MIRRORING A HEARING: ISSUE & RESPOND
This option meant that there was only one round to agree on the issues. In this scenario, if issues are not agreed, then the case would proceed to hearing.
This options was considered as the best approach due to the fact that it mirrors the current appeals process and meant that an appeal would not end up stalling due to the issues of a case not being able to be agreed.
One of the biggest challenges of this project was the technology constraints we had to design within. Although we had been contributing to the reform toolkit and designed and testing our journeys with the toolkit, due to a strategic design from the business and a delay on a release that allowed us to use the toolkit in production, we had to use a technology stack that offered basic configuration out of the box.
This meant that the technology was driving the design and rendered its own user interface.
The initial result was that by using this technology it offered limited functionally and poor user experience. For example, there was no way to have events and therefore every action we have designed for a user to complete had to be shown at every stage of the lifecycle of the process in a drop down menu in the top right of the page. This meant a user would not know what they need to do next.
The view from myself and others on the design team was that users would struggle if not completely fail to complete the journeys that we have designed in our service process.
As we had no other option but to use the limited technology for now, we had to find a way to make the system usable. After understanding the technology a bit more we came up with a number of design solutions.
We used case states to only show the relevant actions (events) to users at a given stage of the process. This also allowed the case to progress forward as certain actions would trigger the case into the next state.
Standard out of the box design
As mentioned above, the technology we had to use to build our service was driving the design, offering limited options in terms of what the user interface could look like. The initial result was that by using this technology it offered limited functionally and poor user experience.
User testing also showed that 80% of users were blocked from getting through the appeal lifecycle owing to events hidden in a drop-down menu.
It was clear to me that this did not meet standard UX principles and patterns. Therefore , we had to come up with a solution that meant that users would be able to succeed first time.
Design solution (Overview tab)
One of our developers identified that we could embed images and text links onto the page by using a basic computer language called markdown. We came up with the idea to utilise this functionality to create a page called the ‘ Overview page’ .
This page acted as a dashboard/homepage and was the first page a user would land on when returning to a case. We displayed an image of a ‘progress bar’ that gave a visual representative of the state the case was in. We also displayed both contextual text links of the ‘next steps’ a user had to perform, linking to their corresponding journeys and persistent text links displayed next to a related piece of content.
There was a different overview page for each case state.
This gave users a sense of orientation and progress of a case and also what actions they might need to perform next.
Our team was one of many teams were constrained by this limited technology to build their service.
We presented our solution to the wider reform and received high praises, especially from the reform head of ux, reform head of content design and the government digital service team.
This design solution went on to win the HMCTS Innovation award that is given out by the HMCTS digital reform programme.
Receiving the innovation award
We identified that there was a clear need for legal representatives and Judges to be able to have structured formatting when writing their legal argument and final decision.
We knew that we would not be able to provide a feature to do this within the scope of the MVP.
We therefore came up with a solution for legal representatives that would allow for a word document to be uploaded containing their legal argument, along with any supporting evidence and for Judges to upload a word document containing their final decision.
This in fact aligned with legal representatives and judges current behaviours as they were used to using word to write legal documents.
Judges write decision via a word template
UI for Judges to upload their final decision
A co-creation workshop was held and facilitated by myself to understand both Judiciary and Case Officers needs. This was in relation to how the journey of preparing and serving an appeals decision and reasons would work in the new service.
From our initial research and analysis we identified that the decision and reason document needed to capture the existing case, users and hearing details along with the main full body judicial findings. In the as-is process this is all currently completed and populated by a judge. It was therefore clear that there was an opportunity to make this process more efficient and less of a burden on a Judge.
The challenge here was that the Judges, who were stakeholders as well as users of the service have been following the same processes for the most of their lives and were initially opposed to change.
Highlighting and articulating the benefit of a reformed process in a simple way was key during this workshop to achieve an aligned vision.
Before the workshop I designed 4 options of how this could work within our service. Even though a completely digital approach seemed appropriate. I decided to offer up different ways to complete the journey incorporating current behaviours that existing users were used to.
I presented the four options above and during the workshop we co-created a 5th option that went on to become the final design for the decision and reasons document.
This option meant that case officers would take on the role of entering basic information onto our system with that then being pre populated onto a word document along with existing data we already have within the system. A Judge can then download the pre populated decision and reasons document and write their full body findings on word and then upload the document and record the decision on our system.
The result was that we could still dramatically improve and digitalise the process, while also not loosing the current behaviour of judges writing their findings within word due to the need of structured formatting. This also meant the workload for judges was less as it would now be split between a case officer and a judge.
We held a workshop that we called a “tea party” that involved all users walking through the service from end-to end using a functional prototype.
This allowed us to really test and validate the full service as we went through every journey and task a user would have to complete to go through the Asylum appeal process.
We had legal representatives, Case officers, judges and Home office case officers all in one room which allowed us to mimic what the real service would be like.
This was an extremely useful day where we managed to capture many useful insights that allowed us to identify the key enablers as well as the potential barriers before we started building the real service.
Tea party workshop (walking through the prototype)
Tea party workshop (discussion with judges & HMCTS staff)
Once we got into the Beta stage we started to build the real product. As we were still user testing some journeys, I created a work process to keep track and manage the maturity of the designs so that they were ready to be built by our developers.
Typically I worked a sprint ahead of the developers and I broke down the designs so they mapped to each user story for the developers to easily pick up and build.
There was a huge work load to do but we managed to get into a sleek cycle of validating, iterating and then signing off the design (by the product owner) ready to be built.
As with many software development projects time is at the essence. There were several times leading up to a sprint where the developers identified that the effort involved to build a particular feature as specified on the design was greater than first expected.
Therefore the already very minimal viable product was getting even more stripped down. I constantly had to battle to keep essential aspects of the design in just so the shipped product would remain usable. For a time it felt like we were going backwards.
Even though it was frustrating to strip down a product that was already very thin, it was clear that we were under pressure to meet our deadline. I therefore decided to take a pragmatic approach.
I still carried on battling to keep the really essential things in (as any UX designer would do) but didn’t want to loose any of the design elements that the team decided were to be stripped out.
I created two user stories relating to a feature, one was for the stripped down version and the other was the for the original feature design and put them in our backlog so they wouldn’t be forgotten about.
I then created a design tracker which referenced the (new stripped down MVP user stories) and the (future user stories) against the journey/feature.
This was really useful to the whole project team as it allowed them see the proposed iterations of a feature and the user stories associated to them.
Design for build tracker
Once we had developed the minimum viable product for Asylum appeals we moved back into a discovery stage to understand how the other immigration appeal types would integrate into the service.
We conducted some initial research and then held several validation/co design workshops to test and develop our thinking.
These workshops involved key stakeholders and future service users, where we first played back our research insights and then co-designed what the end state processes could look like.
We developed some bespoke workshop activities with the goal of uncovering and answering some key research questions.
Over the course of six weeks we held 4 workshop consisting of a number of different topics.
Once we had developed the minimum viable product for Asylum appeals we moved back into a discovery stage to understand how the other immigration appeal types as well as other functionality that was needed would integrate into the service.
We conducted some initial research and then held several validation/co design workshops over the course of six weeks to test and develop our thinking.
These workshops involved key stakeholders and future service users, where we first played back our research insights and then co-designed what the end state processes could look like. We also developed some bespoke workshop activities with the goal of uncovering and answering some key research questions.
After each workshop we produced end state user flows, which we played back to the business. These were then used as the foundations to design into the current minimal viable product.
We grouped the other appeal types and functionality into categories which we defined as topics and split them across 4 workshops.
GROUPED AND LINKED APPEALS
ACCESS AND PERMISSIONS
DECISIONS WITHOUT A HEARING
EUROPEAN ECONOMIC AREA/DEPRIVATION OF CITIZENSHIP
INTEGRATED APPEALS WORKSHOP 2 (4TH APRIL)
FEES AND PAYMENTS
OUT OF COUNTRY
ACCESS AND PERMISSIONS 2
ACCESS AND PERMISSIONS
During this activity we identified some high level permission levels (Limited access, semi limited access, full access) and what level permission our user types should be given.
The discussions during the activity also revealed a split in stakeholders views as to whether the service should formally identify a user as a ‘supporter’ and allow access to a case for a supporter.
Activity: User permissions & level of access
Activity: What/Who is a supporter?
Activity: What makes a good bundle?
We identified that the ideal solution for a bundle was that it needs to be able to be indexed with the ability to change the order of the evidence once uploaded, as well as dynamic pagination and tabbing.
When the bundle is being viewed it also needs to be searchable and easy to navigate, as well as offering the ability to mark up certain sections both privately and publicly.
APPELLANT IN PERSON (16TH APRIL)
We ran a workshop to identify stakeholder requirements and the needs of an appellant when they have to use the service without having a legal representative.
It was apparent for the majority of appellants evidence strongly suggested that representing themselves is going to be a extreamly difficult task. Appellants often are illiterate, don't understand English and have no access to a computer or the skills to use it.
During the workshop we played back research we had conducted with appellants who have used the exisiting service. We then co-designed a number of options that could offer the support needed to guide appellants through the service. We wanted to make sure we covered the needs of appellants across the digital inclusion scale and therefore each proposed option consisted of a range of high and low capability needs.
Appellant in person workshop
Case allocation workshop
CASE ALLOCATION AND WORKLOW (24TH APRIL)
There was a number of internal workflow processes, including case allocation, which need to be accommodated within the new service. We held a workshop to identify the differnt roles and associated tasks that each of the service users needed to carry out throught the end-to-end service
We created a workshop activity (Task sorting), where particpants sorted tasks under pre-defined task types roles. This allowed us to identify who will be doing what within the service.
As an output of this workshop we created a process map as well as inital concepts to show what a case officers and managing case officers interface could look like when viewing and managing workflow and case allocation.
Case officer manager concept
Case allocation concept
Case allocation and workflow process map (Map designed by David Singer)
Website design and content © 2020 Harry Slagel.
Website design and content © 2019 Harry Slagel.
Website design and content © 2019 Harry Slagel.
Website design and content © 2019 Harry Slagel.
Website design and content © 2019 Harry Slagel.