Report Benefit Fraud

Reporting someone you think is committing benefit fraud.



Research, Prototype, Workshops, Design, Development

Problem Statement

Reporting benefit fraud is designed to save the country £1.3bn a year. Therefore, we have observed there is an opportunity to improve the process of reporting. How might we improve this is to carry all reporting to an online offering, removing all paper entries and more importantly cutting down the need for a call center, whilst vastly improving the online service.

The Goal

We require to improve the online approach, updating the UI and platform to align with GOV.UK standards. Easing the user frustrations from using a poor online service and using the phone, and also improve the data given to the investigators to be easy to manage.

What do we know?

- Users need an easy to use way of reporting
- The service needs to be anonymous
- Reports need to be handled quicker and easier

Outcome (KPI)

Increase the accuracy and amount of submissions online.


By improving and converting all submissions online, we can increase the number of valid reports.

User Journey

We researched and tested out as many journeys as we could, with the basis being: provide name/nickname, share what information you have, submit.

Journeys such as:

  • Error reporting
  • What type of benefit fraud to report
  • Information about the person
  • Start page
  • Summary page

User Research

Working with User Researchers, we gathered a vast amount of past examples of submissions from the previous version of the site, ranging from fully finished to hardly completed.

We also sat with the call center to find out what calls were received and how draining it was to keep on top of all the submissions.
We ran usability sessions to find out what was wrong with the current implementation (either online or offline) and how we can improve it in the future.

Recruiting current users of the GOV.UK site, some had submitted a report, all could picture someone to report.
These sessions allowed us to watch the user fill the form in, we found out what the users wanted directly, seeing their frustrations - loudly echoing feedback from our onsite feedback:

1. Quick form to fill in
Users wanted to be quick, sometimes they would do it on their phone on the bus to just wanting to “get it done”, giving as much information needed.

2. Ability to submit even if they didn’t know full information
Users found huge frustration when the form forced you to enter details in - even if they didn’t know full information. DOB or full name caused a lot of stumbling blocks for many.

3. Feeling of anonymous
Most users wanted to provide data without giving their own, they weren’t sure that was the case online.

4. Feeling of “handing it over”
Some users expressed the feeling of relief and wanting to provide as much information as possible as they knew it was wrong, but didn’t have the “success” feeling on the old version.

Users told us

“Is this definitely private?”

“This form is so long, its boring”

“I just want to submit this person, why isn’t it allowing me?”

“I have all this information, where can I put it?”

User Flows

Collating feedback from our users, we agreed that giving the users options to help them complete the form as quickly as possible was the way forward. Providing the user with easy to understand copy to support the options was held up as a must for each step.

What I did

To ensure success, we tried to answer each major user need - concentrating on giving the user a better, quicker and easier experience when reporting Benefit Fraud. With this as a basis, we aimed to provide an easy to understand user journey and used simple, yet useful questions to gain as much data as possible.
We achieved this by working out what the most common submissions were, and giving them upfront as a choice for the user to pick - therefore providing them with questions that were specific and a lot less in number than the previous form.

Aligning the form to the UI of the GOV.UK gave the report a feeling of trust and professionalism, allowing the user to remain anonymous and feel safe when providing the information we required.

What I learned

Work closely with your squad. Sharing every process during the design ideation period, to prototyping to development code - I shared everything I was doing to keep the team in the loop and the feeling of their involvement. This was done easily by including them in workshops, regular sketching and user journey exploration and involving them during usability sessions.

Exploration is key for success. Using as much data as possible, seeing onsite trends, previous submissions and talking to "real" users - we found out so much more than we ever could of imagined, and this really helped to reach a satisfactory delivery.

Go to the next case study
Sky Sports Fantasy Football