How to use service patterns in your organisation
How to use service patterns is something that I know a number of different organisations are starting to think about. This is a conversation that I’ve seen prompted by the LocalGov Patterns library that we’ve been working on at FutureGov with Essex County Council.
Here are some of my thoughts.
Delivering consistency at scale
As a starting point, it’s important to recognise that there are different types of patterns, and that service patterns are usually distinct from the typical type of work that is documented in a ˜Design System (for example, see the GOV.UK design system).
I heard an excellent talk from Lily Dart last month at Create Leicester about designing and scaling design systems for digital delivery (Lily is currently working with Lloyds Banking Group Digital). Lily explained that successful companies realise that to scale delivery they need both high levels of autonomy in teams, and high levels of consistency for design. Design Systems are the solution for supporting this type of digital development at scale.
The challenge here is that there are excellent examples and case studies for how to scale digital delivery, but it’s less clear if any organisations have been able to scale consistency in how teams design full end to end services in this way. Including the organisation design needed around ways of working and supporting operational processes.
Optimising for the design of services
The usefulness of service patterns is dependent on how you understand and start to approach the design of services in your organisation.
A pattern is something that you can work with, and design from, once you understand it better.
Taking local government as an example, if the starting assumption is that many transactions will be similar across councils, the idea of reusable patterns makes a lot of sense. But the focus here in making patterns reusable is mostly about interaction design. This might also be focused on the reuse of common technology components and capabilities. As described before, this is optimising for how you scale digital delivery and the consistency and quality of design in this process.
This is the point where it becomes helpful to start thinking about different types of patterns as part of the design of end to end services.
Moving beyond digital delivery, teams can start to work with patterns across whole services, thinking more broadly about the design of different types of user journeys and future scenarios.
As I’ve shared before, work on service patterns is a valuable exercise and starting point for understanding services from different types of perspective.
The greatest value of the LocalGov patterns library is arguably being able to filter and understand how individual transactions and patterns are linked and relate to one another, especially across different parts of local government. You can apply filters using different life events, thinking more about the role and purpose that a service has when something happens, or when someone is going through a specific situation.
Service patterns are most useful here as a process of understanding how things work, and differences in how things happen, or how they are connected in different types of situations. They then start to show and create opportunities for how things could be reconfigured and work differently in the future.
Scaling the quality of service design
This is a different mindset to patterns being seen only as reusable components, reducing the need for design in order to create, scale and improve services.
Focusing on understanding and working with service patterns might even mean that there is more design required rather than less. This potentially includes the increased cost of investing in design and designers to work on the design of end to end services and user journeys.
Most importantly, service patterns are about delivery of service quality at scale because they help us to better understand how things work, and what needs to happen in order to meet the needs of service users and staff. They can help us to consider the role of our organisation in how a service is delivered, and how this shapes our work with partners and other organisations.
Rather than services that are simply more efficiently delivered because of reusable components, the efficiencies created here are delivered through better designed services. This means less points of failure, offset costs for other channels, and the additional face to face support required when high volume transactions don’t work as people need or expect them to.
Encouraging collaboration from abstraction
Abstraction is important to consider when working with service patterns. There is often a valid argument made that any design patterns without context are difficult to reuse or implement. For example, a generic “pay for something” pattern. But again, when we’re thinking about service patterns the value isn’t exclusively about reuse.
Working with service patterns should be about shaping and informing the start of a design process where you have to work with an understanding of the people and situation that you’re designing for.
Thinking more about abstraction I really liked the thinking here in Neil Tamplin’s blog post:
“Service patterns are not detailed enough to tell the whole story of how something works because there’s a moderate level of abstraction, but it’s just enough detail to recognise that people in different organisations might be doing very similar things that benefit from further joined up thinking.”
Patterns at a service level are also about the potential for collaboration, and for understanding and building on what others are already doing. A documented pattern is what invites the conversation and further collaboration, especially at a cross-sector level. This is where I still think the real value in LocalGov Patterns library might be.
Patterns are obvious, but they’re only a starting point
I’ve previously said that patterns should be obvious, what I call the wallpaper or curtains principle).
When this is the case we should treat patterns like first principles in service design. In this way they act as something that teams can work from with a level of confidence.
Seeing them as starting point is important because it is more efficient to start with what we already know. This includes where we have already designed or delivered something that works in a similar way, or by looking to see if how organisations have approached and designed solutions around a similar set of problems.
Service patterns are less about avoiding how to go back to first principles, and more about having a good set of first principles you have enough confidence to work with or from.
Shared values and direction
Something I’m increasingly thinking about is how service patterns will only be as effective as the values, principles, or standards that teams are working with.
There’s an increasing need for service designers to be able to articulate and work with different service models; this means keeping teams focussed along with a set of values or principles that can shape decisions and guide how decisions are made.
When thinking about how service patterns can help organisations to deliver better services consistently, this depends on how these types of values and service principles are applied.
The GOV.UK design principles act like a set of shared values for how services are designed in UK government. These principles are also supported by a service standard that guides how government teams are expected to work and deliver services. Most of all, these support a consistency at scale for how services are being designed, and for shaping and directing decision making. But, importantly, they also allow individual teams the autonomy they need to design and make decisions based on user research that brings context and a perspective to what they’re working on.
To summarise, the design and documentation of a service pattern (and the technology that supports it) might feasibly become something that’s shared across functional areas in an organisation i.e. where one solution can be consumed or used by multiple services. But, most of all, service patterns should be seen as part of a design process that starts with what we already know about how things work, or could work in the future.
Working with service patterns means working from a shared understanding of your own services, as well as recognising where and how other teams, including those in other organisations, have approached and designed for similar user journeys, needs and scenarios.
Service pattern libraries have the potential to be used as a different type of design system, and as a useful resource for teams to work with and collaborate from. But this relies on designing and being able to scale how you make decisions as the result of future service models, principles and the shared values of your organisation.
A version of this post is now published on the FutureGov blog (Medium).
This is my blog where I’ve been writing for 20 years. You can follow all of my posts by subscribing to this RSS feed. You can also find me on Bluesky and LinkedIn.