15 principles of good service design

Lou Downe, Director of Design and Service Standards for the UK Government based at GDS, is concerned that we don’t have discernible professional standards for service design. Instead of talking “about what we’re trying to achieve when we design a service, we’ve defined *how* to design a good service, leading to endless books and courses filled with diagrams and methodologies”. In short, she says, we still have “no answer to the most basic question “what is a good service?”, so Downe proposes her own 15 principles of good service design:

1. 1. Enable a user to complete the outcome they set out to do
      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.
   2. Be 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.
   3. Clearly explain its purpose
      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.
   4. Set the expectations a user has of it
      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.
   5. Be agnostic of organisational structures
      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.
   6. Require the minimum possible steps to complete
      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.
   7. 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 styles and interaction patterns.
   8. Have no dead ends
      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.
   9. Be usable by everyone, equally
      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.
   10. Respond to change quickly
       The service should respond quickly and adaptively to a change in a user’s circumstance and make this change consistently throughout the service.
   11. Work in a way that is familiar
       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.
   12. Encourage the right behaviours from users and staff
       The service should encourage safe, productive behaviors from users and staff that are mutually beneficial, i.e. the service should not set a precedent for behaviors that may put the user at harm in other circumstances.
   13. Clearly explain why a decision has been made
       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.
   14. Make it easy to get human assistance
       A service should always provide an easy route for users to speak to a human about an issue if they need to.
   15. Require no prior knowledge to use
       A service should not use language that assumed any prior knowledge of the service from the user.

(see also Twitter thread)