15 principles of good service design
What is a good service and why are we so afraid to talk about it? I’ve been asking myself this question a lot recently.
In a bid to find out, I tweeted this a few weeks ago and – bar a couple of people also wondering the same thing – got pretty much tumbleweeds in return.
I’m not surprised. I’ve asked this question many times and had the same response, silence.
Not only do we seem to have no discernible professional standards for service design, but more than that, we don’t seem to think this is a problem.
Before we go on, I don’t mean professional accreditation, or some kind of kitemark for what makes a good service or service designer – I mean the kind of standards that give you an answer when someone asks you ‘how do you know if you’re doing a good job?’.
With almost 80% of the UK GDP generated from services, and an industry that’s (depending on who you ask) between 15-20 years old I find it shocking that we can’t answer this question when so many other disciplines of design can.
Ask a graphic designer to tell you what makes ‘good’ graphic design and you 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.
Ask most service designers this question though, and they’re likely to say something like ‘it depends on the service’ or ‘it’s hard to generalise’.
In the 15+ years of our existence we haven’t yet developed a language to talk about what we’re trying to achieve when we design a service.
Instead we’ve defined *how* to design a good service, leading to endless books and courses filled with diagrams and methodologies and no answer to the most basic question – ‘what is a good service?’
This question is so fundamental to our industry that we don’t even notice it’s missing, but without it we’re spending vast quantities of our time fighting for legitimacy.
This lack of ‘professional standards’ has forced us into an industry-wide existential crisis where we’re never quite sure of our own expertise in relation to everyone else around us.
We criticise the stakeholders we work with for not being able to identify the problem with a given service, whilst in the same breath claiming that service design is a skill that can only be achieved by professional service designers.
Without professional standards we will continue to expect those around us to be able to do more than they can, and not expect enough of ourselves.
We need to understand that most people can spot a bad service, but won’t be able to tell you why it’s bad or how to fix it. This is the same with graphic design – where most people will be able to identify a bad road sign, but won’t be able to tell you that the kerning is too tight. It isn’t fair to expect them to do this, just as it isn’t fair for us to charge for our services as designers if we can’t.
I have lots of theories on how we got into this situation – one of which being that as an industry historically dominated by agencies, it’s never been in our best interest to claim any universal standards when we can charge each client to do this for their ‘unique’ service. Or that fundamentally, we have a collective crisis of confidence where we are afraid that if we tell other people what makes a good service – they won’t need us anymore.
Either way, we need to move beyond this. We need professional service designers to design good services. But we need professional service designers who understand the standards they’re trying to meet.
Not so that we can replace designers with standards, but so that we have an idea of what we need to design.
So, in the absence of anything else, here are 15 principles on what makes a good service. They’re based on years of working on bad services, and trying to build good ones.
You might not agree with them all but I hope that it’s a start to many more competing views.
If you’d like to contribute your thoughts, here’s an open Google doc to start the conversation
A good service enables a user to do the thing that they set out to do from start to finish – be that start a business or learn to drive – in as much of a seamless stream of events as possible. This includes the moment that a user is considering a task to the moment they have completed it – and any necessary steps or support, change or amendment thereafter.
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 purpose of the service must be clear to users at the start of using the service. That means a user with no prior knowledge must understand what the service will do for them and how it will work.
The service must clearly explain what is needed from the user in order to complete the service and what they can expect from the service provider in return. This includes things like how long something will take to complete, how much it will cost, or if there are restrictions on the types of people who can use the service
The service must work in a way that does not unnecessarily expose a user to the internal structures of the organisation providing the service if those structures run contrary to the task a user is trying to achieve.
A good service requires as minimal interaction from a user as possible to complete the outcome that they’re trying to achieve. Sometimes this will mean proactively meeting a user’s needs without them instigating an interaction with your organisation. This may occasionally mean slowing the progress of a service in order to help a user absorb information or make an important decision.
The service should look and feel like one service throughout – regardless of the channel it is delivered through. The language used should be consistent as should visual styles and interaction patterns.
Regardless of whether or not a user is eligible for suitable for a service, the service should direct all users to a clear outcome. No user should be left behind, or stranded within a service without knowing how to continue, or being provided an easy route to do so.
The service must be usable by everyone who needs to use it, regardless of their circumstance or abilities. No user should be adversely unable to use the service more than any other.
The service should respond quickly and adaptively to a change in a user’s circumstance and make this change consistently throughout the service. For example, if a user changes their phone number online, their phone number should be recognised in a face to face service.
People base their understanding of the world on previous experiences. If there’s an established custom for your service that benefits a user, your service should confirm to that custom. For example, users who have signed up to a new service often expect an email confirmation acknowledging their sign up. Avoid customs that negatively affect your user (such as pre-selecting a ‘send me marketing emails’ tick-box) or following customs that are inefficient or outdated.
The service should encourage safe, productive behaviors from users and staff that are mutually beneficial. For users, the service should not set a precedent for behaviors that may put the user at harm in other circumstances – for example, providing data without knowing the use of that data. For Staff, this means they should not be incentivised to provide a bad service to users, for example through short call handling time targets.
When a decision is made within a service, it should be obvious to a user why this decision has been made and clearly communicated to the user at the point the decision has been made. A user should also be given a route to contest this decision if they need to.
A service should always provide an easy route for users to speak to a human about an issue if they need to.
A service should not use language that assumed any prior knowledge of the service from the user.
This article was originally published here.
