Multiple checks

Making a small change based on user feedback


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.

Mapping out the as-is and to-be journeys.

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 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.

Top: initial sketch, bottom: final design.

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.

Left: The checker profile before my changes, right: what the service looks like today with the new button.

← Back to Portfolio Overview