We’ve talked elsewhere about how to make and share service patterns, but now seems a good time to explain in more detail what they do and how important they are.
Service patterns are sets of practical guidelines for building a services (or bits of services) that are repeated across government - something like getting a licence or exchanging the ownership of something.
Right now, services like this are repeated hundreds of times across government in completely different ways, with completely different technology, policy and operational processes underpinning them.
Our theory is that by identifying and refining what good looks like for these types of service, it will make it quicker and easier to build better services that focus on users and easier to link these services across government to meet user needs. They’re one of the tools we’ll be using to make transforming services easier over the next five years.
We have rules for colour and fonts - we can have them for services too
We have established interaction and graphic design patterns for much of the user-facing aspects of government services. From the typography we use to the way we ask a user to complete a form, design patterns guide us.
These patterns help us to create a consistent, but not uniform experience of government. Service patterns are a way of extending this logic. By isolating processes within a service we can improve the way these component parts work and create a truly consistent experience of services across government.
They remove duplication of effort and improve interoperability between services and are crucially - generated from experience and iterated by the design community across government.
In the next five years, service patterns will become consistent standards for the way repeated activities should work, both for users and government.
Like other design patterns, service patterns can be isolated, tested, and iterated on.
A quick example: licences
In our Discovery with DEFRA, we found there were lots of services which fell under the category of licenses.
Though they had many different names - permits, exemptions, certificates, accreditations - and different purposes - registering the birth and death of cattle, movement of livestock, getting a fishing license - they all amounted to the same thing.
They were all licenses, of a sort. They all involved someone or something getting permission from the government to do something (or not do something). But each user journey was different, many were complicated and not user-centred. What became clear was that we could improve the way licenses were granted, and in doing so articulate a service pattern which could be used in other contexts.
The prototype: what we’re aiming for
We need a common format to present the pattern as practical guidance for service managers to build, run and improve services. This format will help us meet user needs at all stages. And having these at our disposal will make the build of services faster and easier.
Our theory is that by using the pattern we can:
- remove the bulk of applications that aren’t eligible or necessary
- and make it quicker and easier for users to get the right permission
This project - identifying existing processes and exploring how they may be optimised in a service pattern - is now in alpha. We are starting to prototype the licensing pattern by working with a team in DEFRA building a service.
Once we’ve tested it the licensing pattern will become practical guidelines on GOV.UK. Service patterns will help us make services cheaper, easier to make and more closely aligned to user needs. That’s why they’re important.