An experience is longer than the screen

---

A digital interface may handle a few minutes of something that takes a person several days or weeks. If we only study the part on the screen, we can miss quite a lot of the experience we are trying to improve.

Someone books a hospital appointment on their phone late in the evening. A letter arrives a few days later. They ask their manager for time away from work and arrange for a relative to collect their child.

Then the hospital moves the appointment. Another letter arrives. A text reminder still carries the old time.

On the day, they find the right building, check in and wait. A receptionist notices the mismatch between the text and the letter and sorts it out. The clinician sees them for twelve minutes.

The booking interface may have worked perfectly well.

It was also a fairly small part of what had to happen.

The person had to organise work and childcare, keep track of changing information, travel to the hospital and arrive at the right place at the right time. Other people became involved along the way. A manager approved the time off. A relative collected the child. A receptionist recovered a problem created somewhere earlier in the service.

Some of those people never touched the product.

This is one of the things I find myself coming back to in UX work. The interface often occupies a much smaller part of the experience than our research, metrics and maps suggest.

A team can improve every screen in the booking flow and still leave the appointment difficult to attend.

The screens may be good. The boundary may simply be too short.

Where we draw the edge

Every map starts somewhere and ends somewhere. It has to.

A map that includes every related event in somebody’s life quickly becomes useless. But a map that begins with the first screen and ends with the confirmation page can leave the reason something succeeds or fails outside the frame.

Service designers have been dealing with this problem for decades. Service blueprinting gave teams a way to see customer activity alongside frontstage contact, backstage work and the processes supporting it. UK government guidance similarly asks teams to look at the wider activity around a service, including offline elements, other organisations and constraints created elsewhere.

The method can stretch quite far. The judgement is deciding how far it needs to stretch for the thing we are trying to understand.

A blueprint might show somebody receiving an appointment letter and later attending the hospital. The space between those two points looks quite small on the page. In somebody’s week it might contain negotiating time away from work, arranging childcare, finding transport, remembering the appointment and dealing with a change of date.

The organisation may have no record of most of that. It sees the booking. Later, it sees the person check in or fail to arrive.

A lot can happen in between.

I’ve found it useful to look for the actions that are carrying part of the outcome even though they sit outside the obvious product interaction. I call these load-bearing actions.

The action itself can be very ordinary. Keeping hold of an appointment letter can matter if that letter is the only place where the person has the reference number, address and phone number together. Getting a manager to approve a morning off can matter even though the manager has no relationship with the hospital.

Once those actions are visible, the experience starts to look a little different.

What happens between the touchpoints

Take the request for time away from work.

A journey map might record this as part of the person’s experience, perhaps as a step between booking and attending. That is already useful. I would also want to know what the service is relying on at that point.

The patient needs their manager to approve the time away. The hospital may have no evidence that this conversation happened, while offering only a limited range of appointments outside working hours.

If the manager says no, the hospital experiences the consequence even though the decision happened somewhere else.

That gives the team something more useful to work with. It can look at appointment times, how much notice people receive and what happens when they need to reschedule. It cannot approve somebody’s leave, but it can decide how much difficulty the service creates around that dependency.

The same thing happens inside organisations.

A system might record referral received as a clean event. Before that event exists, a teacher may have noticed a pattern, decided it met the right threshold, remembered the referral route, found the form and completed it during an already busy week.

Another service might generate the same referral automatically using information it already holds.

Both processes can end with the same neat box on a map.

The amount of human work needed to reach that box is very different.

Digital teams tend to have good evidence around the parts they can see. We know where people abandon forms. We can see failed logins and completion rates. We can observe people using an interface and usually find the point where the design starts causing trouble.

The work before and after the interface is harder to see.

That work can still decide whether the experience succeeds.

Follow one case all the way through

One of the simplest ways I know to find this work is to follow one completed case.

Aggregate data tells us a lot. It can show where people drop out and where problems occur repeatedly. A completed case gives us something different. It lets us see everything that had to hold together for one outcome to happen.

For the hospital appointment, I would start when the person first knew they needed to arrange something and follow the case until the appointment had actually happened. The booking interface would sit somewhere inside that span rather than defining it.

I would pay attention to the people involved, the information moving between them, the bits somebody had to remember for themselves and the moments where another person stepped in to recover a problem.

The appointment case might leave notes like these:

I wouldn’t turn this into five extra rows on every journey map. Most actions don’t need that much attention.

I’m looking for the handful where the outcome depends on somebody doing something we haven’t examined closely.

Following a case tends to make those fairly obvious.

Pay attention to what people carry

Objects are often revealing.

An appointment letter might move from a kitchen table to a manager’s office, then into a bag and eventually onto a reception desk. A screenshot can do the same sort of work in another service. A member of staff might keep a notebook because the official system can only be accessed at the end of a shift.

We tend to describe these objects by what they are: letter, screenshot, notebook.

I’m usually more interested in the job they are doing.

If the letter is the only complete record the person has, it is carrying context through the service. If someone takes a screenshot because they don’t trust the information to remain available, that tells us something too.

People often take on the work that systems fail to carry across a boundary. They remember things, copy them, compare versions and explain one part of the service to another.

When that work breaks down, the organisation may only see the final event.

A person didn’t attend.

A referral wasn’t completed.

A piece of information is missing.

The work leading up to that point can disappear.

People can perform the same sort of carrying work. A receptionist who recognises a familiar mismatch and fixes it before check-in is doing recovery work. A relative who keeps track of somebody’s medication may be holding together part of an experience that the formal service barely acknowledges.

That doesn’t mean every helpful relative or member of staff needs to become part of a redesigned process. It does mean the service should probably know when its success depends on them.

Seeing more does not mean owning more

There is a limit to how far this can go.

A hospital cannot redesign somebody’s employer. A council cannot control everything happening in a family. A product team cannot take responsibility for every event surrounding its interface.

A wider view helps us see where responsibility ends and where dependency continues.

That distinction is useful.

A team may decide to change the interface. It might ask another team to change a letter or work with operations on a recovery route. It might decide that the service is making a promise that depends on too many things outside its control.

It can also reveal places where people are doing work the service could reasonably take back.

A later appointment might remove the need to negotiate with an employer. Better information at a handover might stop somebody having to work out which of two messages is correct. Reusing information already supplied may save another round of form filling.

None of this requires us to map somebody’s entire life.

We need enough of the surrounding activity to understand what the experience actually depends on.

This is one place where design research and behavioural research work particularly well together. Ruth Schmidt has written about the way design research can broaden behavioural problems by bringing context, lived experience and more generative inquiry into the work.

I recognise that problem from practice.

It is possible to ask a precise research question, answer it very well and still miss an action that sits just outside the frame.

Following the experience first helps find those actions. Behavioural evidence can then help us examine them properly: how often they happen, under which conditions, and where the design is relying on an assumption.

I’m still working through how much of this belongs on the artefact itself. A wider map could help teams make better decisions. It could also become cumbersome and harder to maintain.

For now, I find the useful change is smaller.

When I’m looking at a digital experience, I don’t assume the first screen is where it starts or the last screen is where it ends.

I follow the work people actually have to do.

The experience is usually longer than the screen.

Sources and reading

This article draws on established work in service blueprinting, UK government service practice and research on the relationship between design research and behavioural design.

• Shostack, G. L. (1984). Designing Services That Deliver. Harvard Business Review, 62(1), 133–139.
• Bitner, M. J., Ostrom, A. L. and Morgan, F. N. (2008). Service blueprinting: A practical technique for service innovation. California Management Review, 50(3), 66–94.
• Government Digital Service (2019). How the alpha phase works. GOV.UK Service Manual.
• Schmidt, R. (2020). Strange bedfellows: Design research and behavioral design. DRS2020: Synergy.