Beyond the transaction
Designing services that endure over time
In the previous posts in this series, I’ve been describing a system that works exactly as it was designed to. That is the problem.
Public services are not failing because teams lack capability, or because standards are poorly written. They are failing because they are built on an assumption that does not hold.
That a service begins at the point of interaction, and ends when an outcome is produced - often, a digital artefact of some kind.
This assumption shapes everything - funding, definition, building, measurement, even the organisational design of public organisations has been distorted to reflect the limited elements of the digital transformation model that manifested the service factory. It is now embedded so deeply that it often goes unchallenged.
It is also wrong.
What we call a “service” is not the service
In the public sector, service has become shorthand for transactions.
Apply for Universal Credit.
Submit a planning application.
Request support.
The “service” is understood as the mechanism that processes that part of a request and returns a result.
But the service is not the application.
It is the accumulation of information, interactions, decisions, delays, and handoffs that shape a person’s experience of the state over time - including what happens before someone applies, and long after a decision is made.
In other domains, notably in highly competitive markets where companies provide near enough identical products, this distinction is already understood. We call it customer experience.
Customer experience is defined by continuity: whether context is retained, whether interactions build on each other, and whether the organisation behaves as if it recognises the person it is dealing with.
Public services rarely do this. Instead, they reset.
From the system’s perspective, this is efficient. From your perspective as someone accessing them, it is incoherent.
If the reality is continuous, the design must be too
Once you accept that services are ongoing rather than discrete, the design problem changes. We’re long overdue reframing service design well away from how to improve individual interactions, the space we all get stuck in when we’re part of organisations that mistake Service Design (SxD) for User Experience Design (UX).
You need to look at what a service must be capable of if it is to operate across time, across organisational boundaries, and across changing human circumstances. This is not a matter of preference or maturity as much as it is a set of measurable, tangible conditions.
Continuity over completion
The current model is optimised for completion.
Cases are opened and closed.
Applications are processed.
Outcomes are issued.
Success is defined by whether something is finished, but in many areas of public service, nothing is ever finished.
Designing for completion in these contexts produces a predictable pattern: people are processed and return when their situation changes or deteriorates.
Continuity requires services to retain context, recognise prior interactions, and avoid forcing people to start again each time they re-enter the system.
This is why I am encouraging the reframing of services from being ‘transactional’ experiences to ‘relational’ experiences.
Time as a design dimension
Time is currently treated as a measure of efficiency.
How quickly can something be processed?
How many cases can be completed in a timeframe?
These are measures of throughput. They say nothing about what it is like to be in contact with a service over time. If services are ongoing, time must be understood differently. It becomes a question of duration, and of consistency across that duration.
An alternative model would measure not only how long a relationship lasts, but how it is experienced - whether interactions build on one another, and whether the system behaves in a way that feels stable or unpredictable.
This introduces something largely absent from current practice: sentiment over time.
Not satisfaction at a single point, but the trajectory of trust or frustration as the relationship unfolds.
I’m now going to say something that many will cry Heresy. I encourage you to move into the next part of this journey with me with open eyes, and open minds.
Ready?
OK, here we go.
There’s a limiting problem when “starting with user needs”
“Start with user needs” is one of the most widely accepted principles in service design, and stems from the design principles introduced and advocated by Government Digital Service in the UK, later becoming one of the core Service Standards which central government services are assessed against (whether they get funded for the next round of project development).
It is rarely questioned. But it carries an assumption that is often left unexamined.
A person is only a user when they are using something.
The term defines people at the point of interaction, and in our case most likely in relation to a graphical interface. It reduces a complex situation to a moment of contact with a tiny part of a huge system.
For simple, transactional services, like buying a box of pens on Amazon, or even booking a package holiday, this may be sufficient.
But for services shaped by ongoing conditions - health, care, employment, justice - this framing is too narrow.
People are not users in these contexts. They are individuals navigating changing circumstances over time, interacting with multiple parts of the state in ways that cannot be reduced to a single need at a single moment.
To “start with user needs” in these situations is to begin too late, and with too limited a frame.
It focuses attention on the interaction, rather than the condition that led to it and the consequences that follow.
It risks producing well-designed transactions within systems that remain fundamentally misaligned with people’s lives.
For service design to finally become established in the way it is across many other industries - It’s time to let it go.
Where do we go from here?
If services are continuous rather than discrete, if needs evolve rather than resolve,
and if outcomes are shaped over time rather than at a single point, then the model we have been using is insufficient. Not because it is poorly applied, but because it was not designed for this kind of problem.
We do not currently have a dominant model for designing services that operate in this way. And yet these are the conditions that define much of public service work.
If we continue to design services as transactions, we will continue to produce systems that are efficient, compliant, and fundamentally misaligned with the lives they are meant to support.
The question is no longer whether the current model can be improved.
It is whether we are prepared to design for a different one.
From here on out, for the rest of this year, I’ll be documenting my experience of exploring how we radically change this way of thinking, and the instruments, methods, and concepts we use to create change.