Tell HMRC you no longer need to send a tax return

Overview

HMRC’s existing service for people who no longer needed to send a Self Assessment tax return was built on an older iForm platform. Requests usually needed manual review, the form had accessibility limitations, and the underlying user journeys were fragmented across different processes.

I led the redesign of the service around a simpler principle: users should tell HMRC about their situation, and the service should work out what action needs to happen. That meant reducing the number of decisions users had to make, identifying where automation was safe, and redesigning the journey around evidence from user research, analytics and caseworkers.

The service is now able to automate a significant proportion of requests, while routing more complex cases to caseworkers. A major live-service redesign also removed the possibility of many repeat or conflicting requests that had created avoidable work for both users and HMRC.

Role: Service Designer and Content Designer
Organisation: HMRC, through consultancy
Service: Tell HMRC you no longer need to send a tax return
Stage: Live / private beta moving toward public beta
Users: Individuals in Self Assessment who need to leave the service, remove a filing requirement for a previous tax year, or stop self-employment
Scale: Around 20,000 submissions analysed during an early live-service review; later automation reached around 50% for eligible requests

The redesigned service brings several previously separate Self Assessment actions into one journey.

The legacy experience

The existing service was an iForm: a relatively short online form that looked broadly like GOV.UK, but had limited intelligence behind it. Most requests were passed to a caseworker for manual review, even where the outcome was predictable.

The form supported two main actions. A user could tell HMRC that they no longer needed to send tax returns and wanted to leave Self Assessment, or they could ask HMRC to remove a notice to file for a previous tax year where they did not actually meet the criteria to send a return.

The wider ecosystem was more complicated again. Self-employed users were also directed to a separate cease-trading form, which stopped their Class 2 National Insurance liability but did not itself remove them from Self Assessment. Users were then expected to complete their final return and rely on HMRC processes to remove them later.

From a user perspective, the routes, forms and outcomes were difficult to distinguish. People had to understand HMRC’s internal processes before they could work out what action to take.

The legacy iForm captured requests but didn’t follow established patterns or meet accessibility requirements.

Reframing the service around user circumstances

The biggest design challenge was bringing the end of self-employment into the same service without forcing users to understand the difference between stopping self-employment, leaving Self Assessment and removing a previous filing requirement.

I reframed the journey as a form of triage. Instead of asking users which HMRC action they wanted to take, the service asks about their circumstances and determines the appropriate outcome.

For example, if someone has stopped working for themselves, the service asks when they stopped and whether they still need to send a tax return for another reason. If they do, HMRC can stop the self-employment record while keeping them in Self Assessment. If they do not, the service can progress toward removing the ongoing filing requirement.

This changed the mental model from “tell HMRC what transaction you want” to “tell us what has changed, and we’ll work out what needs to happen.”

Screenshot from the user journey showing simpler yes/no questions to establish the path the user should take.

Designing automation around safe decision criteria

HMRC’s main objective was to reduce caseworker effort through automation, but not every request could safely be automated.

I worked with process owners to identify the conditions under which a caseworker would consistently accept a request and which signals required manual review. This allowed the service to automate straightforward declarations while retaining human review for cases involving issues such as bankruptcy, conflicting information or other flags.

The result was an approach that automated roughly half of eligible requests while preserving a route for caseworker intervention where the outcome was not sufficiently deterministic.

An extract from the service blueprint showing how different flags and criteria were used to determine if a case could be automated or sent to a caseworker.

Using live analytics to uncover a larger problem

Once the service was live, analytics exposed a problem that had not been obvious from user research alone.

Out of around 20,000 submissions, approximately 2,500 were repeat requests. Rather than treating this simply as a performance metric, I investigated what those repeat submissions represented.

One example was a user who made separate requests for three previous tax years and then submitted a fourth request saying they had stopped needing to send a return in the current journey. In reality, they only needed to tell HMRC once when their requirement to send returns had ended.

Another issue came from asking when a user last received income. Users could interpret that as the point at which their tax-return responsibility ended, even though HMRC might still require a final return for that tax year.

A tactical content fix

The first response was deliberately tactical. We added clearer guidance to the screen where users selected the type of request, explaining what each option meant and when it should be used.

This was something we could release quickly while the larger redesign was being worked through. It reduced ambiguity without waiting for the underlying service model to change.

A tactical content change clarified the meaning of each request type while the structural redesign was developed – the initial design presented only the question and radio options.

Designing the problem out entirely

The longer-term redesign went further. Rather than explaining the old choices better, I redesigned the entry point so users no longer had to choose between HMRC transaction types at all.

“You have been absolutely pivotal in working to improve and iterate our SA services.”
Stuart Cormack, Product Manager, HMRC

The journey begins with a simple question such as whether the user has stopped working for themselves. Their answer determines which questions follow.

I also designed the service to use an API that was already being introduced across HMRC. This allowed us to identify whether a user actually had previous tax years for which a request could be made and to restrict the journey accordingly.

If a user had already submitted a request, the service could also recognise that state. Rather than allowing another conflicting request, it could tell them the existing request was still being reviewed, or only offer another action where one remained legitimately available.

This meant the service no longer relied on users understanding which administrative request to make. In many scenarios, choosing the wrong action or submitting a conflicting request became impossible.

The redesigned entry point for self-employed people replaced a list of administrative request types with additional, simple questions about the user’s situation.

Changing the question model

The redesign also changed how we asked about dates.

Instead of asking when someone last received income and then calculating what HMRC expected, I reframed the question around the user’s intent: when did they stop needing to send a tax return?

The service could then show the relevant tax years and make the consequence explicit. This reduced the chance that the service would produce an outcome that felt unexpected to the user.

The broader design principle was consistent throughout the service: where possible, users should answer straightforward questions about their circumstances, and the service should carry the burden of translating those answers into HMRC actions.

Early iterations asked for a specific date. Users did not expect to need to send a return for the tax year the date fell into

Bringing self-employment into the same journey

A major part of the redesign was incorporating cessation of self-employment into the same service.

Previously, self-employed users could be directed to a separate cease-trading form even though stopping self-employment, remaining in Self Assessment and leaving Self Assessment were closely connected decisions.

The new journey allows the service to establish whether self-employment has ended and whether the user still needs to send returns for another reason. This means the service can stop the self-employment record while keeping the user in Self Assessment where appropriate, or continue toward full deregistration where it is not.

This reduced the need for users to understand the relationship between multiple HMRC forms and processes.

Suggested caption: The journey separates the user’s change in circumstances from the HMRC action needed behind the scenes.

Suggested alt text: Flow showing how stopping self-employment can lead either to remaining in or leaving Self Assessment.

My role in the redesign

The large-scale redesign was my design direction.

I brought together evidence from repeat-request analytics, user research, caseworker feedback, known operational problems, and my understanding of the new API capability.

I then worked up the revised flow with the Interaction Designer, tested feasibility with Business Analysts and developers, agreed the wording and approach with process owners, and secured agreement from Product Owners to implement the new model.

The API itself was not my design, but I identified how the service could use it to constrain the journey and prevent invalid or conflicting requests.

Outcome

The redesign was intended to prevent user error upstream so that caseworkers did not have to untangle inappropriate, conflicting or duplicated requests later.

The service now determines far more of the correct action based on the user’s circumstances and account state, rather than asking users to understand internal HMRC request types.

Automation for eligible cessation and deregistration requests has reached roughly 50%, with more complex cases continuing to route to caseworkers.

The structural redesign also removed the possibility of many of the repeat-request patterns that had originally appeared in analytics, because users are no longer able to select incompatible actions or submit requests for tax years where no action is available.

Where precise before-and-after performance figures become available, I would add them here rather than overstate the impact without evidence.

What this demonstrates

Live-service design — using analytics and operational evidence to identify problems that were not visible in research alone.

Strategic service design — redesigning the underlying service model rather than simply improving the wording of existing transactions.

Content design — simplifying questions and reframing them around the user’s circumstances and mental model.

Automation and service logic — identifying where automation was safe and where human review remained necessary.

Technical collaboration — designing around an existing API capability to constrain invalid actions and personalise the journey.

Senior ownership — synthesising evidence, setting the design direction and taking the approach through feasibility, process agreement and product approval.