Why farmer facing digital services keep failing: and what good actually looks like 

I spent nearly 30 years working in agriculture, both directly on farms and in government roles. Long enough to watch several generations of digital systems get built, launched, quietly endured, and eventually replaced. Long enough to notice a pattern.

The systems were not badly engineered. Most of them worked: transactions completed, data got where it needed to go. What they consistently failed at was being usable by the people they were built for. That is a different kind of failure, and it is much harder to fix.

Government’s role in agriculture has always been predominantly regulatory: legislating standards, enforcing compliance, and ensuring the safety of the food chain from farm to fork. That remit has expanded to include the environmental impact of farming – emissions, biodiversity, soil health, water quality. The result is a growing body of regulation that farmers must navigate to keep operating.

The tension is real. The farmer’s priority is productive land use, a viable profit, and supplying affordable food in a cost-sensitive market. The department’s priority is ensuring that happens within a framework that protects the wider public interest. Neither is wrong. But that tension shapes every interaction between a farmer and their department, and it is the context in which every digital service in this space has to operate.

Built for the administrator, not the farmer

Open most agri-government portals and ask yourself: whose mental model does this reflect?

In almost every case, the answer is the department’s. Navigation mirrors internal team structures. Language mirrors policy documents. Workflows mirror how an administrator processes a claim, not how a farmer thinks about their farm.

A farmer does not wake up thinking about schemes. They think about animals, land, money, and deadlines. A portal that presents a list of scheme acronyms and expects the user to know which one they need is not a digital service. It is a filing cabinet with a login screen.

For most of the last two decades, agri-digital systems were specified by people who knew the policy inside out and assumed that knowledge in the user. Help desks absorbed the gap. Agents absorbed the gap. Farmers who could not navigate the system rang someone who could. That is not a service. It is a workaround that became infrastructure.

What poor design actually costs

The cost rarely shows up in a project budget. It shows up in call volumes: departments fielding calls from farmers who cannot find something, cannot understand something, or cannot complete a task. It shows up in incomplete applications, missed deadlines, and penalties incurred through confusion rather than intent.

It also shows up in trust. Farmers are not naive users. They know when a system has been designed for someone else. That erodes confidence in the department behind it, which makes every subsequent interaction harder.

What good looks like

The departments that get this right share a few habits.

They start with research, not requirements. They talk to farmers before writing a line of specification – at farm shows, in workshops with agents and advisors, testing prototypes with people who have no prior knowledge of the system.

They design for how farmers actually work. Nearly half of users on some agri-portals now access via mobile phone. A system not designed for that is already failing a significant share of its users before anyone has logged in.

They use plain language. Agricultural policy is full of technical terms that mean something specific in a regulatory context but nothing to a farmer trying to understand their own application. Translating that into something actionable is undervalued work.

They share data back. Departments hold substantial information about individual farms – land parcels, animal records, payment history, compliance status – that rarely reaches the farmer who generated it. A portal that surfaces the right information at the right moment is not just a submission channel. It is a farm management tool.

The shift that matters most

The technology is the easier half. The harder half is changing how teams think about who they are building for. Treating the farmer as the primary user, not as the recipient of an administrative process, requires sustained effort. It means user research sitting alongside policy development, not arriving after the specification has been written.

A confused farmer trying to navigate your portal is more useful information than a completed functional specification.

Departments that have made that shift are delivering better services at lower operational cost. Legacy systems are ageing. Reform programmes are driving new scheme structures that old portals were never built to handle. The question is not whether to modernise. It is whether to modernise in a way that actually works for the people using the result.

Done well, that means fewer calls, better compliance, and the kind of trust that makes every future interaction easier.

Oliver McWilliams is Version 1’s Agriculture SME and a former civil servant with DAERA. He works with agricultural departments across the UK and Ireland on digital transformation and technology strategy.

To find out more or to join the next Agri-Forum, get in touch.