What is a service?
When designing a service, there are many questions we need to answer - who are our users? What do they need from us? What could we do to help them achieve their goal?
But there is one question we’re often afraid to ask. It’s by far the most common question that comes up in Good Services courses, and that’s ‘what is my service?’
This question often comes allong with an apology for the ‘stupid question’. But it’s far from a stupid question.
Defining your service wrongly at the beginning of any piece of service design (or redesign) is one of the most common mistakes a team can make, it can mean the difference between a service that works and one that fails spectacularly and it’s a question we need to get better at asking.
You can't design a service if you don't know what a service is
Before we define what our service is we need to understand what services actually are in the first place, and the challenge we have is that the word ‘service’ is so ubiquitous that it’s used to describe many different things, most of which aren't services at all.
For some organisations, the word ‘service’ means ‘customer services’ (usually a call centre or other response team) for others, the ‘service’ refers to a technology system that operates a particular business function (eg. ‘CHIEF tax code service’) but for most, ‘services’ are a way of categorising the activities of the organisation and organising them in a way that makes sense for us to run (eg. ‘Business Banking’, ‘Waste’ or ‘Drivers Services’).
A service is something that helps someone to do something
This is very different to the way our users see services.
To a user, a service is very simple. A service to a user is something that helps them to do something.
That ‘something’ can be short and straightforward, like buying a chocolate bar, or it can be long and multi-parted, like moving house. What unites all services is that they help us to achieve a goal, however big or small it might be.
The parts of that service might be provided by a number of different organisations, but to a user, a service is one continuous set of actions towards that end goal, regardless of who is providing it.
When we think about services in this way, we end up with services that are often much larger than the ones we had before. They can even involve other teams and other organisations.
It’s our responsibility to work with the other teams and organisations involved in delivering our service. Just because you don’t provide the whole service, doesn’t mean you’re not responsible for the outcome.
Your service will will involve multiple teams, and often multiple organisations. For example ‘getting treatment for my health concern’ might involve the the following steps, each is provided by a separate part of the NHS
Services are activities, not categories
This is radically different from how most organisations see services. Most of the time we see ‘services’ as a way of categorising the things we do in our organisation.
‘Services’ provide a neat filing system in which to organise all of our people, systems, policies and processes into groups that make sense to us to deliver.
But like any filing system, the way we categorise services is intensely personal to the organisation doing the categorising and we end up categorising ‘services’ in a way that makes sense to us to deliver, rather than what makes sense to our users.
When we do this, our users face the challenge of rooting through our filing system and trying to second guess how we might have defined the thing they’re looking to do.
Your user defines what your service is
Unless we design our services to help our users achieve the goal they’re trying to meet, we leave it to our users to do it for us. They become ‘meatlinks’. Human beings doing the job your service should be doing of connecting the disparate systems, processes and products involved in that task into something that enables them to do the thing they set out to do.
This means that as the creators of our services, our users are often the only ones who actually know how to use them.
Unless we get to know what our user needs to achieve, there’s no way we can know the answer to the question ‘what is my service?’ and unless we can answer that question, there’s no way to design a good one.
You can have all of the carefully facilitated workshops you like about what the service is or isn't but ultimately you don't get to decide, you’ll need to do some user research to find out.
Beware of services that are too big, or too small
Because we use services as a way of categorising the things we do rather than arranging the things our user needs to achieve their goal, we can end up with services that reflect what is easy for us to provide, not what our users need.
Essentially we’re like a restaurant that arranges its dishes by how long something takes to cook, rather than by whether it’s a starter, main or desert.
As a consequence of this we either lump every user need into one giant portal-esque service with a seemingly endless list of options to choose from - or we allow users to only complete a tiny, isolated fraction of the things they need to in order to do the thing they set out to do - in essence we make services that are either too big in their scope or too small.
Services that are too small
Where your ‘service’ is one tiny sliver of an overall task that a user needs to complete to do the thing they need to do.
Sometimes this is done for efficiency reasons, particularly with large complex services that use separate ‘services’ to route different types of users to different outcomes. For example ‘use service no.1 for business tax, service no.2 for personal tax…and service no.397 if you have business tax but live abroad and imported a car between 1979 - 1996’…and so on. Sometimes this is done to avoid ‘overreach’ of the service to keep its scope constrained where other organisations or teams are known to provide other parts of the service.
Whatever the reason, the result is the same - a type of nightmarish choose-your-own adventure experience where at any point, a user may choose the wrong route and end up in a service that isn't the thing they needed.
Services that are too big
Equally as common and just as frustrating are services that are too big. These services lump all of the potential user needs around a topic or area into one portal or account and call it a service.
Again this is usually done for efficiency reasons and in the name of creating one platform to do EVERYTHING or manage all of the content and services in one place. This can also be taken as an approach because of indecision around what the services are, or as a way of managing complex services with many threads that are difficult to pull apart.
How to define your service
Defining the scope of our service is the most important task we can do when designing a service. Now that we’ve understood what services are, here are some simple things we can do to help us answer the question of ‘what is my service?’
Your service will be a combination of the purpose of your organisation (eg. build more affordable into housing) and the thing your user needs to achieve (eg.find houses I can afford in my area)
Understand your purpose
Every service has a purpose. Be it to help people get access to affordable housing or sell dog brushes, we have a specific thing in mind we want to achieve.
Your service is a combination of what you want to achieve, and what your user needs to get done. It’s important to know both sides of this equation.
Start by asking the question, what do we want to achieve by providing this service? does it match what we are currently delivering or plan to deliver? How does the thing your user needs to get done intersect with what your organisation is aiming to achieve?
Where your service starts will be on a spectrum from the thing your user needs to do, to the thing your organisation thinks about providing.
Understand what your users need to get done and, what they think exists as a service to help them achieve that
Your user defines what your service is by what they’re trying to achieve. That means they’re going to be typing something into google looking for it, or asking friends, family or colleagues for advice.
What they search for will not just be based on what they're looking to get done, but how knowledgeable they are about what might be available to help them. Google is the hope page to your service*, and unless your user can get from that initial search to your service, they’re not going to be able to use it.
When we speak to our users, we need to understand not just what they’re looking to achieve but what services they think exist to help them do that.
Ask yourself, what does your user want to achieve? What does your user think exists as a service that could help them to get there? what are they going to look for when they encounter your service?
Be patient
This is likely to be a very different way of seeing services to the way your organisation currently views them. You’ve probably got financial, physical and people structures that support the current categorisation of services, and that will take time and effort to unpick. You’ll need your organisation to come with you on this journey to see services in this way.
Try testing the name of your service with your users, and invite your stakeholders along. Walk them through the questions above and be patient. This is a complete mindset shift, it won't happen overnight.
Don't be afraid to iterate.
We think once we’ve defined our service that’s it. Our service is set in stone forever more. In reality, our user needs will change over time, so will our purpose of our service, and over time our service needs to change scope too.
Constantly review the scope of your service. Is it still right? Is it getting too big, too small? Does it still help your user achieve what they need to do AND deliver the purpose you need it to deliver?
* if your service is an internal service, read ‘your intranet’ or equivalent internal search function
If you’re interested in learning more about how to define your service, The School of Good Services has courses to help, from understanding more about what makes a good service in our intensive 1-day Designing Good Services masterclass to how we manage those services in our 2-day User Centred Service Management course
