Making it easier to prove your rights in the UK(5 min)
Background
The UK’s immigration system is changing and so is how people prove their rights in the UK. The Status project at the Home Office is responsible for creating the online services that allow people to prove their right to work, rent and access other benefits whilst living in the UK.
The family of services
The task of digitising the immigration process has been incremental. Work continues to make it simpler to prove your rights online. But for now, there are three separate services that people or ‘sharers’ must use:
- Prove your right to work to an employer
- Prove your right to rent in England
- View and prove your immigration status
Each of these has a counterpart which allows ‘checkers’ - employers, landlords and other organisations - view a person’s status.
Proving your rights is complicated
To share your immigration status, you need to give someone a ‘share code’. Like the key to a lock, a share code will only let the checker into the same service from where it was generated. This makes sure that only information that is relevant to the reason for checking is shown.
Because the three services do very similar things, the pain for users comes from not knowing which code is the right one to share. With the wrong code, checkers have to go back and forth with the sharer to get the correct one, delaying processes which leads to someone missing out on employment opportunities or a place to live.
The problem
View and prove your immigration status is the newest service. Part of its initial design was to try to stop the wrong codes being shared. A page in the service which lets users choose a reason for getting a share code. In theory, this should send the user to the right service for them. In reality, users were still generating the wrong codes. We set out to fix this and improve outcomes for both shares and checkers.
| Service name | View and prove your immigration status |
| Organisation | |
| Period | 09/21 to 04/22 |
| Phases | Live / continuous improvement |
| Role | Interaction Designer |
Simplifying choices
The first iteration of the choice page had a list of radio options with specific reasons to get a share code. Research found that users would select ‘other’ and enter in a reason already listed above.
Before I joined the team, the list was cut down to try and reduce misinterpretations. We soon realised that this was just recreating the original problem the page was trying to solve.
Before and after of simplifying list of options
Testing different variants of content
At first glance, the options seem clear. In research however, we found users chose ‘right to rent’ to get social housing and ‘right to work’ to get a National Insurance Number, where the correct choice would have been ‘view and prove’.
I brainstormed with the UCD team to test different ideas:
- We surfaced the most commonly used and misunderstood reasons in hint text.
- I suggested reframe the question being asked.
Our researchers suggested a ‘first click’ test to measure the success of each design against each other. We sent this out to 30 users and found that design C - with the most hint text - was the most successful.
This confirmed my belief that it was still not clear, users needed lots of content to help them make the right choice. This could seem to be putting a plaster on a wider issue and could introduce problems for users with differing access needs or those who speak English as a second language.
Mock-up A with original content
Mock-up B with listed hint text and reframed question
Mock-up C with listed hint text
Mock-up D with shorter hint text
Proving that the service must work for everyone
Our stakeholders at this time were applying pressure to settle on the simpler content changes from first click testing. But knowing that this would not fix the issues for everyone, we aimed to prove that more work was needed.
Aphasia is when a person has difficulty with their language or speech. It's usually caused by damage to the left side of the brain (for example, after a stroke). Our researchers conducted a round of research with an aim to understand the difficulties faced by someone with aphasia when navigating through the service with the help of their carer.
I built a prototype of the end-to-end use journey, including the successful design from our last round. I worked with the researchers to identify which scenarios would be the most effective to test.
The research showed that the user struggled throughout the service, particularly when they had to remember information from a page before or make a decision from lots of options. This proved our point and justified why we needed to keep working.
Changing the journey
I felt that we needed to try something different. I looked at some resources and found the GDS pattern on checking a service is suitable. By splitting the journey into three steps, the user only has to make binary decisions.
Our researchers recruited participants from different backgrounds, all current or prospective visa holders who had not used the service before. I had a set of assumptions I wanted to test and I fed these into the discussion guides.
We found that users were better able to make the choice which fitted their scenario. It also seemed that they understood that there are different types of share code and that they needed to choose the right one.
Flow of choices in the step by step journey
Iterations
Now that a journey was validated with users, we did a further round of research to iterate and improve other parts.
Finding: When users answered ‘no’ to both questions, they were confused that they were taken straight to their share code.
Solution: I added a page that informed users that based on their answers, they needed to use ‘View and Prove’.
Outcome: Users were confident that this was not a mistake in their journey. They were confident that they were in the right place, though some noted this was only through a method of deduction - answering ‘no’ to the ones they were certain weren’t right for them.
Page to confirm choices, with hint text
Finding: Users could not find a way to get a share code. We initially thought that ‘proving your status’ was the goal that users would be trying to achieve but we found that the most common term used was ‘get a share code’.
Solution: We renamed the button to ‘get a share code’ to match the goal they had in mind.
Outcome: All users were able to find the start of the share code journey every time.
Improved entry point of the journey
Outcomes
In an ideal world, one service could fix all of this for users. But as with most continuous improvement projects, stretched budgets and decisions made five years ago meant that we had to make do with implementing small but important improvements.
With the evidence that we had collected from the rounds of design and research, I was able to make a set of suggestions to our stakeholders:
- implement the step by step journey but carry with users of lower digital literacy and users with a range of different access needs
- implement content changes on the profile to make the entry point clearer
Whilst I do not believe we got a conclusive and perfect solution for all users. We have been able to gather valuable insights from our users and have the motivation to keep improving the service.