Why Services Degrade at the Edges

The short answer

Services do not fail uniformly, they fail at the edges. These are the specific moments where the design’s assumptions about user behaviour turn out to be wrong. Every assumption is a bet on behaviour, and every point where the bet is wrong is a point where the service is structurally exposed. The pattern worth understanding is that gaps usually appear where the design was most confident rather than where it was most complex. Complexity attracts attention and testing effort. Confident assumptions pass under the radar, because at the time they do not feel like assumptions at all.

Your service works for users who do not exist

Your service works perfectly for users who behave exactly as you expected. Those users are not the ones who turn up.

Every digital service carries a set of assumptions about how people will move through it.

We assume users will: 

• Enter correct information the first time
• Complete the task in a single session
• Not change their mind halfway through

Each of these is reasonable as a starting point, and each is a bet on behaviour. Where the bet holds, the service works. Where it fails, the service is structurally exposed, because nothing was designed for what happens next.

The assumptions rarely get written down, which is part of the problem. They are embedded in the shape of the journey rather than stated anywhere a team could review them. A flow that moves from entry to confirmation in four steps has assumed, silently, that nothing interrupts those four steps. That assumption is both load-bearing and invisible at the same time.

A worked example

Consider a designer reviewing support call data for a utilities switching service, three months after launch. The happy path works correctly. Enter your details, run the comparison, select a plan, confirm the switch. It had an 87 per cent completion rate in testing. In live use, 34 per cent of users abandon the journey at the confirmation screen.

The related support calls reveal three patterns behind that abandonment:

• Users who started on mobile and want to finish on desktop
• Users who want to check their current contract end date before committing
• Users who cannot tell whether the switch includes their gas supply or only their electricity

None of these were accounted for in the design, and none of them are a rare occurence. They were entirely predictable, which is what makes their absence from the design significant. This was not a failure to anticipate the unforeseeable. It was a failure to examine what the design had quietly assumed.

Fragility follows confidence, not complexity

The instinct when looking for weak points in a service is to look at the complicated parts. Complex logic, unusual flows, technically difficult interactions. These attract design attention and testing effort precisely because they look difficult, and the attention they receive tends to make them robust.

Fragility gathers elsewhere. It gathers at the points the team was sure about, because certainty is what stops you looking at things in detail. A confident assumption does not feel like an assumption while you are making it. It feels like knowledge, and nobody tests knowledge in these circumstances.

This is why the centre of a journey is usually sound and the edges are where things come apart. The centre is where the team looked hardest. The edges are where they did not look, because they were sure they already understood the user. The confirmation screen in the utilities example is not technically complex, it is the point where three unexamined assumptions converged.

How to find the assumptions before users do

Because these assumptions are invisible by nature, finding them requires a deliberate exercise rather than a general commitment to thinking carefully. The most direct approach is to take a journey and, step by step, state what the design assumes about the user at that point.

For each step, ask what has to be true about the user’s situation for this step to work as designed. Consider if:

• They have the information to hand
• They are on the same device they started on
• Nothing has changed since the previous step
• They understand what the previous step did

Each answer is an assumption, and each assumption is a candidate to be a point of failure.

Then ask the second question, which is the one that produces useful design work: what does the service currently do when this assumption is wrong? If the answer is that nobody knows, or that it gets handled in build, you have found an edge. That is where the service will degrade, and it is where design attention will pay for itself.

Instead of asking where does this service break, ask where we assumed users would behave in a specific way, and what happens when they do not.

Frequently asked questions