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.
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 fewer 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: