The actions your service depends on
Services often rely on a handful of human actions to make the whole thing work. An audit of 14 design artefacts looks at whether our maps make those dependencies visible enough to judge them properly.
---
A surgeon finishes an appointment. An AI tool has listened to the conversation and drafted the clinical note. On the service blueprint, the next step looks straightforward enough: clinician reviews the generated note.
There is quite a lot hiding inside that sentence. The clinician needs to spot anything the AI has misunderstood, decide what belongs in the medical record and correct the draft where needed. They have to do that reliably, in a setting where some appointments last ten minutes and attention is already split between the patient and the record. If the review is rushed or skipped, the effect reaches further than one missed step in a workflow. The accuracy of the record depends on it.
I keep coming across actions like this in service design, behavioural work and AI projects. They tend to appear as fairly ordinary bits of activity: review note, make referral, respond to alert, use tool. Some carry far more of the outcome than the map suggests.
I’ve started calling these load-bearing actions: things a person has to do, or keep doing, for a particular outcome to hold up. I find the term useful because it changes what I notice when I look at a service map. I’m less interested in whether an action is present than in how much the service is asking that action to carry.
A verb can hide a lot of work
Camden Council’s independent travel training work is a good example.
The council wanted more eligible young people with special educational needs to take part in training that could help them travel independently. Its behavioural research found that school staff generally understood the value of greater independence. The referral itself was harder.
Staff didn’t use the process very often, so it was easy to forget. Some weren’t clear about who should make the referral. Some didn’t know enough about what happened next. Talking to parents about independent travel could also bring up reasonable concerns about safety.
On a workshop board, all of that can become complete referral.
That label isn’t wrong. Maps have to compress things or they stop being useful. But inside the school, somebody still has to notice that a pupil might be suitable, remember that the service exists, find the right information and raise the idea with the family. Someone then has to complete the referral alongside the rest of their work.
The map shows the action. The research around it gives a better sense of what the action asks of people.
I find the same thing in AI adoption. The UK Government Communications Service created a monitored adoption path for Assist, its generative AI tool. The path included receiving an invitation, completing training, logging in for the first time and returning to the tool. Sustained use was defined as logging in at least once a week, aggregated monthly.
That gives the team a sensible measure of use. It can tell them who came back.
Claims about improved work need more than that. Someone can log in, try a vague prompt, get something unhelpful and go back to the way they worked before. They still count as a sustained user. If the expected benefit is time saved, the team needs some connection between use and the time spent on a relevant task. If the concern is quality or safety, it needs some account of what people do with the output and how they check it.
A service can therefore have a perfectly measurable action and still know relatively little about the behaviour its outcome relies on.
What our maps make easy to see
I went back through 14 public design artefacts to see how much of this information was already visible. The set was deliberately mixed. It included service blueprints, journey maps, behavioural diagnoses, operating models, business-model artefacts and AI workflow maps.
Most were good at showing activity. Twelve showed the actor clearly. Twelve showed the action. Ten gave enough context to understand when it happened.
The picture became thinner when I tried to work out how much the outcome relied on the person doing that thing. Six made the connection between action and outcome explicit. Three said how much or how often the action needed to happen. Four attached evidence to the expectation. Five made a fallback visible. Six gave enough information to understand something about the burden being placed on the person doing the work.
It is a small public sample, so I wouldn’t use those counts to make claims about design practice as a whole. They were still enough to sharpen the question for me.
A lot of our artefacts already contain behaviour. People are all over them, doing things. The part that is often harder to read is the dependency sitting behind those actions.
Arrows make this especially visible. A line between two boxes might mean that one step happens after another. Elsewhere it might indicate influence, responsibility or the movement of information. That usually works while the people who made the map are still around to explain it. Someone can point at the line and say what they meant.
A few weeks later, the same artefact may be in a steering-group pack, being read by someone who wasn’t in the room.
The Department for Education wrote about creating a “just enough” journey map during an alpha. The team needed a shared picture while it was still experimenting, and planned to add fuller business processes during beta as the artefact took on a wider role. That feels sensible. A map used by a team to think together can leave quite a lot implicit. Once people start using the same map to judge a proposal, approve funding or make changes, some of those hidden meanings become more relevant.
Take a sequence like:
School identifies pupil → school makes referral → pupil receives travel training
It gives a useful view of the process. If I’m trying to judge how plausible the service is, I also want to know that uptake depends on school staff identifying suitable pupils and making enough suitable referrals during their existing work.
That leads me into different questions. Do staff encounter enough suitable pupils? Do they recognise them? Does referral fit naturally into the points where those decisions are already being made? How many referrals does the service actually need?
The arrow worked. But we are simply asking more of the artefact.
The conditions around the action
A study of monitoring technology in home-based dementia care gives another version of the same issue. People with dementia and their families valued the reassurance that monitoring might provide. Care professionals could see how it might reduce unnecessary visits. They also described a practical problem: live monitoring could create care needs at awkward times.
If a sensor detects a possible fall in a bathroom at two in the morning, somebody has to receive that information and decide what to do with it. On a service map, that might appear as respond to alert.
The usefulness of that instruction depends heavily on the conditions around it. Who receives the alert at two in the morning? Are they actually working? How quickly can they respond? What authority do they have if the usual care team is already dealing with something else?
The same action can look perfectly manageable during office hours and become much harder during a night shift. I’ve seen versions of this in plenty of service work: something that appears to be a behavioural requirement is partly a staffing, authority or capacity problem.
Fallbacks can shift the service in similar ways. During the digital-scribe project, the design team considered what should happen if a clinician’s microphone failed. A support route sounds modest when it is written beside the workflow. Providing one might require customer-support skills the company doesn’t have in-house, or another provider altogether. A small recovery step on the map can therefore create work elsewhere in the service.
This is the part I now pay more attention to. When an apparently simple human action appears in a map, I want some sense of how much work is sitting inside it and how much of the outcome depends on that work happening well.
Mark the few actions carrying a lot of the outcome
I don’t think every box on a service blueprint needs another layer of behavioural annotation. Most maps are already doing enough.
I would start with the outcome the team cares about and work backwards through the service. An action deserves closer inspection when the outcome would materially change if someone did it badly, late, too rarely or not at all.
For those actions, I usually want enough information to understand who has to do what and when, which outcome depends on it, how well or how often it needs to happen, and what evidence supports that expectation. I also want to know what gets in the person’s way, what happens when the action fails, and who can change the conditions if the problem sits outside that person’s control.
That information doesn’t all need to live on the main map. A linked note might be enough.
The digital-scribe example could carry something like this:
An orthopaedic clinician checks the generated text before it enters the patient record. Record accuracy depends on this check. The review standard and time allowance still need agreement. Current evidence comes from job shadowing and concept testing rather than live use. Recording faults need a recovery route. The clinical owner and ongoing review burden still need to be decided.
I like this kind of note because it leaves some uncertainty visible. It shows what the service is relying on without pretending the team already knows everything it needs to know.
Labels such as observed, reported, inferred and assumed may also help. They give a later reader some sense of where an expectation came from without filling the map with research notes.
There is still work to do on the idea. Fourteen public artefacts are enough to find something worth investigating, but not enough to tell us how widespread the pattern is or whether adding this information actually improves decisions. Which is why I started looking in the first place.
The next useful test is with practitioners. Give people an ordinary service blueprint and ask them to assess the service. Give another group the same blueprint with a little more information beside its load-bearing actions. Then look at the risks they notice, the evidence they use and the recommendations they make. Let me know if you team wants to take part.
If I’m honest, the extra information may help… but it might also make the artefact harder to read or maintain.
For now, I’m using a simpler practice in my own work. When a service map contains an ordinary-looking human action, I spend a little longer asking what is sitting on top of it.
____
And for those you want the specifics. Here are the audited resources and my analysis.
Service blueprints
Department for Education (2025). Building a service blueprint.
Kim, D. and Cho, J. (2023). Analysis of the Health Examination Service Process Using Service Blueprint: Focus on the Older Adult Patient in South Korea. Healthcare, 11(20), 2709.
Journey maps
Department for Education (2025). Visualising our service in alpha.
Cabinet Office (2025). The People Factor: A human-centred approach to scaling AI tools.
Behavioural diagnoses
Department for Transport (2025). A behavioural science and systems thinking approach to assess and enable AI readiness in DfT.
Camden Council and Local Government Association (undated). SEND travel support behavioural insights case study.
Business-model artefacts
van Limburg, M., Wentzel, J., Sanderman, R. and van Gemert-Pijnen, L. (2015). Business Modeling to Implement an eHealth Portal for Infection Control. JMIR Research Protocols, 4(3), e104.
Wrede, C., Braakman-Jansen, A. and van Gemert-Pijnen, L. (2022). How to create value with unobtrusive monitoring technology in home-based dementia care. BMC Geriatrics, 22, 921.
Operating models
NHS England, NHS Improvement and NHSX (2021). Information Governance Operating Model 2020-2022.
Sheffield City Council (2022). Future Design of Adult Social Care.
AI workflow maps
Magyari, R. and Secomandi, F. (2023). Service Blueprinting for Better Collaboration in Human-Centric AI. International Journal of Design, 17(3), 63-77.
Boag, W. et al. (2024). The algorithm journey map: a tangible approach to implementing AI solutions in healthcare. npj Digital Medicine, 7, 87.
Project decision records
GOV.UK Design System team (2018). JavaScript for less-capable browsers.
GOV.UK Design System team (2023). Reset the JavaScript API for our components.