Multiple checks
Making a small change based on user feedback
Background
Status is a project that is in the ‘continuous improvement’ stage. It consists of 3 sub services: right to rent, right to work and view and prove. These services have 2 sides: checkers and migrants.
Team structure
- 2 Interaction Designers
- 1 User Researcher
- 1 Content Designer
The challenge
While viewing user feedback in the Feedback Explorer (Feedex), our user researcher noticed that checkers would encounter an error when they tried performing consecutive checks. This error occurred across all of Status’s 3 services. Our researcher logged tickets and brought the issue up at our regular weekly prioritization meeting. As I had just joined the team and the Home Office in general, my project mentor assigned the issue to me as she thought it would be a good introduction to public services. I was happy to accept the challenge!
The Process
Using the design thinking model, I first focused on understanding the issue. I was new to working on services, so I wanted to ensure I knew the user journey and familiarized myself with the service itself. Using our test accounts, I tested the journey myself and then created user journey maps of the as-is journey before thinking about how it could be improved. This was so I could understand the current roadblock and jot down my initial thoughts on how to overcome it. Next, I explored design options.
Design and testing
I started sketching, keeping it very high level and low fidelity.
My initial designs included a button group. This is a design pattern from the gov.uk design system, so users are familiar with the format. There was also a caption saying “what you can do next”.
Once I had some options, I presented it to the team to get their feedback.
I also started moving the design into the code prototype we use for testing so we could eventually test it with our users.
My hypothesis was that users would be able to perform another check by clicking the button without any guidance. We were able to test the new user journey a couple months later along with other changes made to the Status services.
Usability testing confirmed this hypothesis as users breezed through the consecutive check and didn’t need any prompting from the researcher. As a team, we felt comfortable to hand this solution over to development.
Then, I prepared the handover files and presented the solution to the development team, explaining how I came to this conclusion and how it performed during research. They were happy to pick this up.
The outcome
These changes have since gone live and are fully functional on the production service.
← Back to Portfolio Overview