I’ve gathered these notes a while ago after reading it. I will start to put my notes from books (or recorded talks for example), as blog posts for me, but also, to be able to share with people who don’t have time to read.
Please note: I recommend reading the book. It doesn’t take much time and will give you examples to really understand the principles.
Some links
- Lou Downe’s book has a whole website where you can buy it but also buy posters, see the scale templates they created based on these principles and now some classes you can register for.
- The GOV.UK service manual: Designing good government services: an introduction
- Amazon, Airbnb, and Asos are all investing in this one simple design idea
Notes
A service is something that helps someone to do something
Pre internet era services still account for the vast majority of services we use and were designed for a very different world to the one we now live in. We often don’t rely on a new technology until that technology is ubiquitous. since we don’t have a clear definition of this, the more cautious organisations often lag well behind, waiting until the majority of their customers use a particular technology before changing their services.
The simple fact that our services weren’t designed for the channel they’re delivered in, is one of the most common causes of service failure.
A timeline of services
- 1800s: letters
- 1920s: forms
- 1960s: forms + support
- 1970s: process + forms + support
- 1970s: process + forms + customer service
Services today are composed of small component pieces joined together through data or user experience to form a seamless user journey that helps a user achieve their goal.
In a way, each service is broken down into steps, and each steps into a series of tasks. Each one of these tasks will probably be called ‘a service’ by the person running it. What defines the edge of a service is very dependent on your context, so if all you do all day everyday is provide surveys, it’s easy to think of the service as providing surveys.
Your user defines what a service is by what it is they want to achieve
The way your user thinks and talks about your service is likely to be different to the way that you do.
A good service should:
1. be easy to find
… by a user with no prior knowledge of the task they are set out to do.
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.
Good services are verbs, bad services are nouns:
For most organisations, services are individual discrete actions that need to be completed in a specific order (like ‘account registration’). 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 internally.
Over time, these names become exposed to users, even if we don’t mean them to be initially.
We often place users in a situation where to find something they need to know exactly what they are looking for.
Google is the homepage of your service
The name of your service makes a statement to your user about what your service does for them.
Nouns are for experts, verbs are for everyone
To name your service: avoid legal or technical language, describe a task, not a technology, don’t use acronyms.
2. clearly explain its purpose
The purpose must be clear to the user at the start of the service. A user with no prior knowledge must understand:
- what the service does
- why it does it
- how it does it
- who it is for
You need to clearly communicate this by the service name and description and even the interface of how it works.
3. set a user’s expectations of it
Explain what is needed from the user to complete the service, what the user can expect from the service provider in return (for example: how long something will take to complete, how much it cost, any restrictions).
Before wondering how you’re going to manage your users expectations, it’s important to understand what expectations they have in the first place. Most people base their expectations on past experiences. You need to do your research.
There are 3 types of expectations:
- universal (fundamental to your service – to monitor closely, but not need to explain it)
- assumed (things a user don’t know about your service – most important to explain upfront)
- outliners (only some users but need to keep an eye because it can become a universal very quickly)
It’s important to consider all 3 types when designing. Try to meet as many of these expectations as you can and when you can’t, explain why.
4. enable each user to complete the outcome they set out to do
- understand what your user is trying to achieve
- get a good understanding of who else deliver all of this service and how they relate to your organisation
- look at your organisation’s ability to deliver all of this service – if not feasable, then define what a rational scope for it your part of that end-to-end service will be
- consider which part of the service it makes senses to deliver first – start small and build or improve in increments
- look at how data gets shared between the organisations delivering the service – are there things you could share that would make it easier for your user? or things that you need from organisations that would enable you to provide a better service?
Design whole services from end to end: from when the user starts trying to achieve a goal to when they finish
From front to back: the user-facing service and internal processes
In every channel: digital, phone, post, face-to-face and physical elements
5. work in a way that is familiar
- research how your competitors work and look for patterns in what they do
- understand if there is an easier, more intuitive or more effective way of doing what your are doing
- if there is, test it to understand how different this is from your user’s existing expectations of how your service might work
- make sure that any changes you make are intuitive
- share the changes to the way your service works with others so that your pattern can become ubiquitous
Make things open: it makes things better
6. require no prior knowledge to use
In recent years, a new generation of ‘parasitic services’ have evolved to help us negociate some of the more cumbersome and difficult to understand services. There is often a cost to it, which means some users who can’t afford this are excluded.
It’s particularly prevalent in the public sector, where there are many services who believe their users to be brokers, conveyancers, tax specialist or legal advisors.
Our understanding of a new service is based on past experiences
When people don’t know how something work, they make it up
- make sure your service is findable (look at the language your user use to look for it) (principle 1)
- clearly explain what your service is for (principle 2)
- make no presumption about how much your user knows
- work in a way that is familiar (principle 5)
- work in a way that is agnostic to organisational structures (principle 7)
7. be agnostic of organisational structures
The service must work in a way that doesn’t unnecessarily expose a user to the internal structures of the organisation providing it.
For the first time, we are facing unprecedented demands to join up our services that finally match our ability to do something about it. Providing these joined-up services poses a number of challenges that go beyond what skills we have or what software we use.
There are 4 fundamental ways our services are designed that cause siloed, fragmented journeys, despite our ability to join those up across organisational boundaries.
- separation of data
- incompatible processes (different deadlines for example)
- incompatible criteria of use
- inconsistent language
Getting something done is always more important than who is providing the service
Collaboration is the new target operating model
If collaboration was easy, we’d all be doing it. The reality is that it’s very hard to start, and even harder to continue. People in different parts of an organisation, or other organisations altogether, work at a different pace, have different objectives and sometimes even financial incentives that mean that they are often at odds with one another.
4 things to support people to collaborate on one shared service:
- permission: allow people to step outside of their day job to work together
- shared standards
- shared goals (and everyone fully getting behind)
- shared incentives
In summary:
- recognise the potential silos in your organisation – or with other organisations that might be providing parts of the same services
- if you can’t change your operating model, change the way you communicate and collaborate
- consider things that create a permissive environment for collaboration, like shared standards, goals and incentives, to help people work together
8. require the minimum possible steps to complete
Everything new steps in your service is a transitional moment. The difference between choosing something and buying it, or between buying and returning it.
The number of steps in your service should be equal to the number of decisions your user has to make, no more no less
A good rule of thumb is to think for yourself: if this thing was done automatically without my knowing about it, would that be a good thing? if the answer is no, then it’s best to create a separate step to your service to make sure that your user has full visibility and control over what they are doing.
Don’t just design the steps of your service, design the space between them
Involved services: slower steps (medical services for example)
Transactional services: needs to be done very quickly with as little interaction as possible
In summary:
- review where decisions need to be made in your service (look at your service end-to-end)
- allow users to focus on one task at a time
- think about how fast or slow your steps need to be
9. be consistent throughout
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 style and interaction patterns.
A service can be inconsistent between steps in this service or between channels, for example the online channel might be well designed the set of values and processes has not been communicated to the rest of the organisation (face-to-face or phone)
A strength held in one area should be consistently shared across organisation.
Good services are only as strong as their weakest link
While it’s vital for services to be consistent, they are also complex and varied, and some parts of your service will need to look and behave differently from the rest. For example, how you talk to your users when they sign up for an account is different to how you then talk to your users when they have a complaint that needs solving.
Good services are consistent, not uniform
4 dimensions of consistency: across user journey, in each channel, over time, between users
Principles:
- every breach of consistency is a breach of trust
- focus on the abilities of your whole organisation, not on the skills of your superstar players
- empower staff to make individual decisions about users
10. have no dead ends
A service should direct all users, regardless of whether the user is eligible or suitable to use the service. No user should be left behind or stranded within a service without knowing how to continue.
4 main reasons for dead ends:
- they’re not eligible to use your service
- they’ve strayed off the beaten track
- they can’t do something (unable to remember a date, follow complex instructions, go somewhere physically, do something during working hours, read a pdf, or service is not accessible)
- they don’t have access to something
Things that most services presume users have access to:
- phone number
- bank account
- email address
- ID
- an address or proof of address
- any of the above in the country you are operating in
How you can mitigate dead ends in your service:
- provide onward routes for people who aren’t eligible to use your service
- ensure your service is inclusive
- minimise the number of ‘requirements’ you ask your users
- build affordances (alternative routes)
- let your service degrade gracefully (when services fail, you can rely on the technology that came before it)
11. be usable by everyone, equally
The service must be usable by everyone who needs to use it, regardless of their circumstances or abilities. No one should be less able to use the service than anyone else.
There is no such thing as a ‘normal’ user
Inclusion is a necessity, not an enhancement
Lack of diversity in your team = Lack of inclusion in your service
To try to see why someone might be excluded from your service, think of:
- What they do: try to think in terms of strengths and weaknesses. Try to consider both short term reasons why someone might have an issue and long term ones as both group might have very different adaption strategies
- who they are (gender, age, ethnic background, sex, religion …)
- what they have (transportation, friends, home, money, education)
Inclusion means that your user can not only use your service but feel safe, welcome and use it in a way that make them feel equal to all other users
Make sure your service is: safe, perceivable, understandable, operable, robust, and equal.
inclusion is like making blueberry muffin – it’s a lot easier to put the blueberries in at the start than at the end.
Cordelia McGee-Tubb
12. encourage the right behaviours from users and service providers
What’s measured gets done
- remember what you are trying to achieve
- make sure you focus on balancing the behaviours you expect of your staff and your organisation. Don’t just focus on one of these
- make sure that the outcome you want to achieve is encoded in every layer of your organisation, from its business model and staff targets, right down to the way your users interact with your service
13. quickly respond to change
How you check something has changed is as important as making sure your service responds to that change
When thinking about how to manage both direct and indirect changes to your service, consider the following:
- some changes should be predicted, and some can be expected. Work on the assumption that nothing is fixed – make it easy for users to change things about themselves
- make a list of all the changes that might happen to a user when using your service and work out which ones need to be directly designed for as functionality, and which don’t
- for changes that directly change the way your service works, always give the users the option of doing this at the point that this information becomes relevant, but always make sure they’re aware of who knows about this change and what that information will be used for
- not all changes should be universal; always give users the ability to share only what they want to share with the people they want to share with
14. clearly explain why a decision has been made
How you make a decision is as important as what decision you make
When designing decision-making in your service, make sure:
- your decisions are valid
- your decision are transparent
- your decisions are communicated
- there is a way to appeal your decision
15. make it easy to get human assistance
Use computers and humans for what they are good at
What differentiates your service is not whether or not it fails, but how it deals with failure when it happens
Hiding your phone number just pisses people off
Factors that increase the need for human contact within a service; services that are:
- complex
- high risk
- high value
- tied to the physical world
Regardless of the channel, principles to follow when making sure your user can access the valuable skills of a human:
- be accessible when they’re needed (when time critical for example)
- proportionally used
- empowered to make decisions (remove organisational boundaries and ensure they are experts and multiskilled)
- consistent with the rest of the service
Study by GDS in 2014
- 80% of the cost of government is on services
- up to 60% of that cost is spend on calls and case work
- about 43% of these calls are status chasing calls
- 52% where questions about how to do something
- 5% were complaints
- 2% about complex cases