will get a different answer each time, but at least they’ll give you an answer. That answer will crucially be based on well-known industry-held ideas of best practice that are taught in design schools across the world – things like the grid system, basic principles of typography or use of iconography. Yet despite the fact that what makes a good service isn’t as subjective, service design has traditionally had no such understanding of best practice.
Almost 80% of the UK’s economy is generated from services, a figure closely mirrored by the rest of Europe and North America. The industry of service design (depending on who you ask) is between 15–20 years old and yet, instead of defining what we mean by a good service, we’ve focused on how to design them.
This has led to the creation of a seemingly endless list of books and courses filled with methodologies and diagrams, and no answer to the most basic question: ‘what is a good service?’
Because of this, we spend vast quantities of our time fighting for the legitimacy of service design. After all, how many other professions or activities are unable to answer the question: ‘what does doing your job well look like?’
We need to move beyond this. Not so that we can replace user research or design with standards, but so that we can focus our efforts on learning and responding to the things that are unique about our services, not relearning the things that aren’t.
This book isn’t a to-do list of everything that will make your service work for you and your users – there will be things you will find along the way that are unique to your organisation or service – but it will tell you where to start.
The principles in this book have been crafted from years of experience working on some of the best and worst services in the world and honed by thousands of contributors around the globe who want to answer the question – what does it mean to make a service that works for users?
It depends
There are some things we all need from all services
1
A good service is easy to find
The service must be able to be found by a user with no prior knowledge of the task they set out to do. For example, someone who wants to ‘learn to drive’ must be able to find their way to ‘get a driving licence’ as part of that service unaided.
The first step in providing a good service is making sure that your user can find your service. This might sound simple, but it’s a lot harder to do than it sounds.
Staff at a small rural UK county council discovered this to their horror in late 2016 when, after opening their information desk at 9am on a Tuesday, they were approached by a man carrying a dead badger. The man slammed the badger down on the desk, much to the shock of the customer services manager, proclaiming that he had found it outside of his house, and didn’t know what to do with it. ‘I tried looking on the website,’ he said. ‘But I couldn’t find “dead badger” on the list, so I came here.’
Not every situation is as hard to figure out as what you need to do when disposing of a dead animal. After all, it’s not something that happens every day. However, just as the man with the badger did, your users will come to your service with a preformed goal that they want to achieve. This can be very simple, like ‘dispose of a dead animal’ or ‘learn to drive’ or ‘buy a house’.
Where your user starts will depend on how much they’re already aware of what services might be available to meet their needs. Your job is to make sure that they can get from this goal to the service you provide, without having to resort to support. Or dropping off a dead badger at reception.
To a user, a service is simple. It’s something that helps them to do something – like learn to drive, buy a house or become a childminder. This means that, to a user, a service is very often an activity that needs to be done. A verb that comes naturally from a given situation, which will more than likely cut across websites, call centre menus and around carefully placed advice towards its end goal. The problem is, this isn’t how most organisations see their services. For most organisations, services are individual discrete actions that need to be completed in a specified order – things like ‘account registration’, ‘booking an appointment’ or ‘filling a claim’.
Because these isolated activities need to be identifiable for the people operating them, we’ve given them names, nouns, to help us keep track of them and refer to them internally. Over time these names become exposed to users, even if we don’t mean them to be initially.
In government, these are things like ‘Reporting of Injuries, Diseases and Dangerous Occurrences Regulations 1995 (RIDDOR)’ or ‘Statutory Off Road Vehicle Notification (SORN)’ – but the names private organisations give these things are no less obtuse. Names like ‘eportal’ or ‘claims reimbursement certificate’ are commonplace in the private sector.
Good services are verbs
Bad services are nouns
Google is the homepage of your service
Without understanding what our users are trying to achieve, and reinterpreting our services in language that our users can understand, we often place users in a situation where, to find something, they need to know exactly what they’re looking for. For a user to find a service like RIDDOR or SORN, they first need to know what you call your service, resulting in an additional step being added to your service – that of learning the name that your organisation calls the thing they’re trying to do.
As with the case of the dead badger, the less you know about the situation you’re in, the support available to you or what you should do, the harder you will find this search. Needless to say, even the most patient people wilt at the prospect of this almost impossible task. Instead their confusion drives to them to call centres or, worse, they won’t use your service at all.
Google is the homepage for your service. Whether your service is usable online or not, this is likely to still be the way that it will be found and accessed. When it comes to finding your service, nothing is more important than its name. Beyond making it easier for search engines to index and list your service, the name of your service makes a statement to your user about what that service does for them.
The UK Ministry of Justice found this out when they set about changing its Fee Remissions service in 2017. The Fee Remissions service helps to pay for or subsidise the cost of court fees for people who aren’t able to pay themselves. However, it doesn’t take a genius to realise that the word ‘remission’ is not the most frequently used word, particularly in a financial content. Given that the financial literacy of those applying often wasn’t high, the title of the service was not only hard to understand for most people, but served to weed out precisely the users who were eligible to use it.
The reason this happened is simple, and happens every day in the creation of services. The title of the policy, somewhere long ago, had simply been made into the name of the service, without a thought to what language a user might use.
Nouns are for experts
Verbs are for everyone
Several rounds of research with the users of the service and staff providing it revealed that it was often referred to as ‘help with court fees’ rather than ‘fee remissions’, so the team renamed the service, meaning that users with low levels of financial literacy