Once a problem becomes clearer, it is tempting to fix the visible point immediately. But a delay, error or ambiguity may arise at the boundary between several parts of an organization. To see those boundaries, we need a map of how work actually moves. An organization chart shows who reports to whom. A service map shows how a need reaches an outcome, with help or obstacles along the way.
Begin with the need, not the form
Imagine someone contacting a retailer to repair an appliance. This is a hypothetical example. Their experience does not begin when they open a request page. It begins when the appliance stops working and they need to find out what help is available. A ‘request received’ message is not the end either. They need to understand what will happen and eventually have a usable appliance again.
GOV.UK’s guide to mapping a user’s whole problem distinguishes the user’s journey from how the service is delivered. Alongside touchpoints, it considers backstage processes and the people involved. That perspective helps prevent the boundary of a screen or department from being mistaken for the boundary of the problem.
Visible work and backstage work
On one line, record what the requester does: find a contact route, explain the problem, arrange a handover and receive an answer. On another, record the organization’s work: check information, decide whether to accept the repair, coordinate it and communicate. Connect the lines wherever information or responsibility moves. The points where work stops often become visible at those connections.
In the repair example, support may give a clear reply while the promised timing has no connection to the workshop’s actual capacity. A repair may also be finished without anyone being responsible for notifying the customer. Do not explain that situation simply by blaming a person. The map should make the dependency discussable: what information must reach whom, when and under whose responsibility?
One map can conceal different experiences
GOV.UK’s guidance on creating an experience map grounds the map in users’ experiences and advises separate maps when groups follow substantially different paths. It describes actions, thoughts and feelings over time, rather than merely listing screens.
Someone who finds an answer online may follow a different route from someone who must call. A straightforward repair may differ from one requiring a replacement part. Instead of packing every detail into a crowded diagram, begin with a specific journey and keep important exceptions alongside it. Distinguish areas without evidence from confirmed findings using a note or a visual convention.
A map should support a decision
A map’s appearance matters when it makes relationships easier to read, not when it merely makes a workshop output look impressive. For each point of friction, identify its effect on the user, the evidence available and who needs to help examine it. An uncertain connection may first need observation. An unassigned responsibility may need an agreement. Duplicate entry may need a rethink of the information flow.
Review the map with the people doing the work. If they say, ‘In practice we take another route here,’ do not remove that informal path. It may reveal a constraint concealed by the official model. A useful output is not a perfect document ready for archiving. It is a shared, revisable picture that makes choosing the first change more precise.