Government · UX Research
A new government import system was about to get an email notification service, copied wholesale from the EU system it replaced. Before committing two sprints to build it, research with 22 importers found most were already ignoring, filtering, or disabling exactly that kind of email, so the team killed the feature before a line of code was written, saving over £140,000.
Working with our Lead Researcher, I interviewed 22 importers to find out what they actually did with the existing system's status emails. Most had already disabled them, filtered them into junk, or marked them read without opening. We recommended not building the feature, stakeholders agreed, and the two sprints of development time went to other roadmap items instead.
IPAFFS (Import of Products, Animals, Food and Feed System) was built to track import status changes for goods entering the UK after Brexit. Those imports could take hours, days, or weeks to clear, and often included live animals and fresh produce. Missing a status change could mean spoiled or endangered cargo, so keeping importers informed mattered.
The plan on the table was to replicate the EU system's email notification service. It made sense on paper: the old system had it, the business requirement assumed it, and importers ranged from individuals tracking a single shipment to large operators running hundreds at once. Nobody had actually asked those importers whether the emails helped.
Instead of accepting the notification requirement, I worked with the Lead Researcher to write a short interview questionnaire and ran it with 22 importers, covering people who managed single imports and people who managed hundreds at a time. The question wasn't "would you like emails": it was what people actually did with the ones the current system already sent.
We synthesized the findings into a clear recommendation and took it to stakeholders: don't build the notification service, because the dashboard was already doing that job.
The dashboard already answered the question the emails were trying to ask, and importers weren't missing the notifications by accident; they'd built systems to avoid them: disabling them, filtering them into junk, marking them read without opening.
All 22 of 22 importers interviewed had already tuned the old system's status emails out
n = 22 importers interviewed, ranging from single-shipment to hundreds-at-once operators
That held whether we talked to someone tracking a single shipment or an operator running hundreds at once. Both groups had already formed the habit of checking the dashboard on their own schedule.
The emails weren't filling a gap. They were noise on top of a habit that already worked.
Every group we spoke to (solo importers and operators running hundreds of shipments) converged on the same behaviour: check the dashboard directly, treat the inbox as noise. That consistency across such different usage patterns is what removed the doubt from the recommendation.
Importers were spared a notification service they were already avoiding in the old system, and the dashboard stayed the one place they needed to check.
Over £140,000 in build cost avoided, and a full development team freed for two sprints and redirected to higher-value roadmap work.
The best design decision is sometimes the feature you don't build.
I'd push for this kind of research earlier, in requirements gathering, before a feature gets far enough along that two sprints are already earmarked for it.