We’ve released new patterns and guidance to help design services. You can find them on the Service Manual. They have emerged from work we used to call licensing patterns.
With this new work we're focusing on creating patterns for ‘tasks’ or elements of a service, rather than trying to create patterns for the service or license as a whole.
I’m going to talk about three of these patterns over a series of blog posts. I’ll start with the naming your service guide.
Tasks, not licensing patterns
Before I say more on the naming your service guide, I want to quickly explain why we’re not talking about licensing anymore.
First, the name was confusing. People found it too abstract. When we’d say ‘licensing pattern’, it wasn’t clear what we meant. People understood it broadly meant consistency, but that was about it.
Second a service and licence aren’t the same thing. A service is a group of tasks that helps you to do something. Like sell alcohol or learn to drive. A licence is the outcome from doing those tasks. It could be in the form of a photocard, certificate or registration number.
And third, we were working at the wrong scale; we were trying to make one super-pattern, that applied to every single service where you get a licence.
We realised after trying to build one that instead we needed some smaller patterns. Patterns for the most common tasks which together make whole services. Tasks like checking eligibility, uploading a file or saving and returning. We’ve started a list of potential patterns relating to common tasks.
Although we've changed the way we approach patterns, the principle behind them remains the same. They can be created once and used again and again across departments to build a number of different services.
So, on to our most recent guide: naming your service.
Naming services better
Service names are important. They are how users find your service online and understand what it does.
The process of naming a service is also when that service starts to be built. It’s deciding what the service should be. Naming is also a proxy to asking ‘Are we building the right thing?’
Deciding what to call it is the most important conversation you can have about a service.
A guide to having that conversation
We already have strong and informed opinions about service names. However, these weren’t written as guidance or collected in one place. This meant that the advice GDS gave teams on naming their services could be inconsistent or incomplete.
We know that the Service Manual is commonly consulted when teams are going from discovery into alpha. Which is the point at which they need to start thinking about a service name. Putting this guidance in the Service Manual therefore puts it at the point of user need.
The guidance page includes:
- when to name your service
- how to name your service
- examples of service names
- how to check how the name is performing
In our next blogpost, we’ll talk about adding a new pattern to the Service Manual; check before you start.
Follow Harry on Twitter and don't forget to sign up for email alerts.
