Menu

Digital Transformation

Why most digital transformation starts in the wrong place

Most digital transformation programmes don't fail because of the technology. They fail because they start with it.

Why so many transformation programmes invest in platforms and interfaces before fixing the underlying experience, and why that order of operations keeps producing the same results.

28 March 20264 min read

In short

Why so many transformation programmes invest in platforms and interfaces before fixing the underlying experience, and why that order of operations keeps producing the same results.

What looks like progress often isn't

New get introduced, are redesigned, and there's a lot of visible activity. On paper, it reads as momentum. In practice, very little has changed.

The mistake is framing as a technology exercise. Upgrade the , rebuild the , migrate the data, and the experience will improve as a result. But the experience isn't produced by the technology. It's produced by how everything fits together: the journeys, the processes, and the decisions that sit behind what the user is being asked to do. If those things aren't examined, you don't get transformation. You get a newer version of the same problems.

Visible activity is also what gets reported upwards, which keeps the framing in place. milestones fit neatly into a status update. Establishing that a journey should be restructured does not, so the work that would change the outcome stays invisible to the people funding it.

If the journeys, processes and decisions behind the experience aren't addressed, you don't get transformation. You just get a newer version of the same problems.

The structure is usually the problem

At Co-op Bank, years of and had shaped how journeys worked in ways that were invisible from the inside but immediately felt from the outside. Customers were navigating that made internal sense but carried unnecessary weight. Rebuilding the interface wouldn't have changed that. The structure itself needed rethinking, step by step, within real constraints.

The NHS presented the same issue at a different scale. Hundreds of sites, multiple departments, inconsistent regional approaches, and no coherent structure tying it together. Previous consolidation attempts had failed, not because the was wrong, but because they started with the and inherited all the inconsistencies already baked in. What worked instead was stepping back, understanding how people actually used the , and rebuilding the architecture from the ground up before any technology decisions were made.

What both had in common is that the structure was never anybody's explicit responsibility. It was the accumulated residue of decisions made for other reasons, and because no one had created it deliberately, no one felt able to change it deliberately either.

Key takeaway

Transformation tends to fail when it starts with platforms and interfaces instead of questioning how the experience is structured underneath.

Where transformation usually goes off track

Most programmes start with solutions rather than problems. There's an assumption that the existing structure is broadly correct and just needs modernising, and that the issue is presentation, not . In most cases, that assumption is exactly where the trouble starts.

The assumption is rarely stated, which is what makes it hard to challenge. Nobody writes down that the current is broadly right. It is implicit in the shape of the programme, in the budget lines, and in the fact that the first workstream is a selection.

Testing it early is cheap. Map the two or three journeys that matter most as they actually work today, end to end, and ask whether the shape is right before anyone evaluates a vendor. That exercise usually takes a fortnight and regularly changes the programme.

What working transformation looks like

When works, it begins with understanding: what users are actually trying to do, where they struggle, and why. It looks at how journeys are shaped across , teams, and , and questions whether those journeys need to exist in that form at all. The outcomes that follow (shorter journeys, clearer decisions, less effort from the user) don't come from new technology. They come from rethinking how the experience works.

It also tends to shrink the scope. Understanding what people are trying to do frequently reveals that a large part of the planned work serves a that should not survive the , which is a better outcome than building it faithfully into something new.

Technology should follow the thinking

Technology still plays a critical role, but it should enable the experience, not define it. When the structure is right first, technology becomes easier to implement because it's supporting something that already makes sense. When it's the other way around, teams spend months working around that were avoidable.

Approaching from the experience backwards consistently produces better results. Understand how things work today, where is coming from, what needs to change. From there, design and technology decisions become significantly more straightforward.

isn't about replacing what you have. It's about fixing what isn't working. And most of the time, that starts long before a single line of code is written.

The sequencing argument is easier to make commercially than it sounds. Structure work is comparatively cheap and reduces the amount of that needs buying and configuring. Doing it first usually lowers the total cost rather than adding to it.

Written by Andy Scott

Strategic design, UX and digital transformation thinking from real projects.

LET'S WORK TOGETHER

Ready to improve your product?

UX, research and product leadership for teams tackling complex digital services.

Previous feedback

I had a fantastic experience working with Andy. One of his most impressive achievements during our time at NHS HEE was masterminding a deeply complex information architecture for a new platform that brought together a large number of legacy websites.

Will Parkhouse

Senior Content Designer