In Part one, I wrote about what we had done to get started on service patterns in the NHS, with a little history. In this post I wanted elaborate on what we think service patterns are (right now), and what we’re working towards.
What are service patterns?
Here’s Tero’s definition:
‘Service patterns are reusable steps found across many NHS services, such as booking an appointment or checking eligibility. They set out the shared user needs, actions, and design principles so teams can create consistent, user‑centred services.
Patterns do not necessarily deliver an end‑to‑end service. Even with a full set, teams still need to decide how steps connect and design what is missing. A pattern can take you most of the way, and the rest is adapting it to the specific service and local delivery model. This is also why patterns work well for national services that require local tailoring.
By reusing the common parts of a service, teams save time and avoid redesigning the same step repeatedly. This means they can focus on the elements that are new or complex.’
Nice.
They basically describe replicable pieces of services that can be combined to build or shape end-to-end services (here’s a good gov blog on it if you want more).
The potential benefits of service patterns are huge. It’s much more efficient to not start from scratch all the time, and all of a sudden the NHS starts to feel more joined up. You could move from one part of the country to another and feel like you’re interacting with the same services.
Obviously the data that sits in all these different systems is another thing altogether, and solving fragmentation won’t be done just with service patterns. But it can help.
There is also the fact that with service patterns you can embed good ways of working, outlining best practice and embedding accessibility and inclusion in the patterns themselves.
If someone comes along, then, and picks up a load of patterns to start a new service, they will be doing so with building blocks that are properly considered, and build that new service on solid foundations.
So what will ours look like?
It’s all up for debate and will change, but in our recent workshop, we pulled out several things we think patterns are about:
- They should be flexible (more on that later)
- They are efficient
- They should provide some context about its use and other patterns that it might impact up- or downstream
- They should give us shared language
- They should include historical knowledge
- They should be inclusive
- They should feature structured layers of connected service ‘material’ (guidance, needs, content, data, etc.)
- They should exist for citizens/ patients/ staff
We also thought that they might include (at a deeper level of detail):
- Steps
- Descriptions
- Principles for implementation
- Data flows
- Standards to use/ adhere to
- Outcome metrics
- How outcomes lead to improvements in the system
National vs local
One of the major barriers we have in the NHS to creating service patterns is the sheer amount of complexity that exists. It’s not just that there’s one central team creating and owning services in one area — like it might be for a central government department (though not trying to play down how hard it is for them too).
We have a number of organisations working to deliver services. A lot of them aren’t run at all by the NHS, and there’s also a huge dynamic at play between nationally built services and how they’re delivered locally.
For example, let’s take breast screening. There is a central programme team and a digital team within NHS England. Then there are 77 separate breast screening offices around the country that deliver breast screening in their own areas.
From recent research, one striking aspect of it is how different each breast screening office is. It has to be to an extent. Each office knows how to best deliver the service in their area, given the types of people they’re trying to screen (some have more older people, or different communities); they have different facilities; and it changes rural vs urban.
How then do you create a single pattern for something like ‘book an appointment’ where that pattern must exist in thousands of places.
And even if you create a great pattern, how do you even roll it out?
White label
Our thinking thus far has therefore been around creating ‘white label’ patterns, where we create an 80% pattern (whatever the hell that looks like), leaving space for personalisation.
This means you could have a nationally mandated white label pattern for something like ‘book an appointment’ that anyone can take and contextualise.
If the rules and rationale around it are clear, the implementation should be good. But it could create situations where patterns are bastardised or misused (though that could happen to fully formed patterns too).
It would be a huge helping hand to whoever is starting with an 80% done pattern, and save them a lot of time and effort revisiting work that’s already done.
Consolidating knowledge
So much knowledge is lost in big organisations.
At the very least, we think (right now) that patterns can be useful vehicles to store knowledge around a certain thing. Everything we know, everything we can think of, all goes in one place.
Therefore any designer coming to it for the first time has a massive headstart and knows what there is, what there could be, and what work has happened to date.
We can do all that without specifying what the pattern should look like, and instead point to examples where it has been used. This would be easier on our part and you would think quite valuable.
This point brings me to our users.
Who we think these are for
In our workshop we identified a number of users of service patterns. We will need to develop this further, but we think it could consist of:
- Designers (service, interaction, content, research)
- Tech Architects, Engineers / Developers
- Policy and senior decision‑makers
- Product and delivery roles
- Teams with low or uneven design capability
- New starters and less‑experienced teams
- NHS and non‑NHS system partners
- Clinical assurance and clinicians (questioned)
That was in priority order, with most voted for at the top.
We did some thinking about what exactly each role might want from patterns, but we need to discuss further as we go.
Conclusion: it’s all about efficiency
Even with the most basic version of service patterns (consolidating knowledge) we think they could be useful and mean that no one has to start from scratch every time they need a common pattern.
There is almost certainly efficiency gains to be made.
However, we also need to bear in mind that if we’re too prescriptive then it will become inefficient. What we need to do is strike the right balance.
We are currently working on taking two patterns (check eligibility and book an appointment) to stress-test the approach and see how they might work for us.
We’re also working on our comms. Hence this.