What makes for a good user-centred public service?

We’re doing some thinking about how to understand the maturity of a government in using service design in its public services.

How can we measure the quality of public services, or, put another way, what makes public services ‘good’? That’s ‘services’ plural, because we’re interested in the bundle of things that a person might need from a government rather than, for example, ‘renew your driving licence’ taken in isolation.

From ninety minutes of chatting about basic principles of user-centred design and moving things around on a Miro board, we’ve got a loose starting-point.

Thoughts from a Miro workshop

Good public services need to:

• As far as possible, do the hard work to make complex processes simple for users.
• Situate users in the wider journey.
  This involves letting them know how long it will take to complete a service, and updating them when they need to submit more information, or when their application status changes.
• ‘Bring joy’ or, at the very least, be somewhat aesthetic.
  We spoke about using services with outdated design patterns which weren’t pleasant to use. A clear user interface can vastly improve our experience of a service.
• Be supported by a strategic view of how different services will interact; or, alternatively, be integrated such that data/logins/permissions are shared between services without this having been mandated by senior civil servants (many useful integrations are bottom-up initiatives; we should also celebrate successful ‘muddling through’ ).
• Be efficient.
  This is twofold.
  1) People don’t want to spend much time getting whatever they need from the government. They have better things to do. Services need to be efficient for users.
  2) Efficiency also relates to public value for money. Ultimately, users pay for the services we use, and public resources have to be distributed according to political priority and among groups with competing interests.
• Be accessible.
  1) To be accessible to everyone, services need to be built in line with Web Content Accessibility Guidelines. This involves making sure that content is:
  - perceivable (content can be identified, either visually or via screen readers or other means);
  - operable (different users can operate the service, for example, all functionalities might be offered by keyboard);
  - understandable (users can understand the content and how to use the service); and,
  - robust (the service can be understood by a wider variety of users and is compatible with a range of assistive technologies).
  2) Moreover, services that are accessible to everyone need to have clear language. People who use the service need to be able to understand what’s being asked of them. Depending on the context, services also might need to be accessible in a range of languages.
• Be inclusive. When designing public services, governments also need to take into account that their users will not be homogenous. Public services need to be inclusive and able to accommodate a wide variety of users with different needs
• Be ‘respectful’ of the people using them.
  Services need to treat their users as human beings with genuine needs, as opposed to trying to be punitive or catch people out.
• Actually achieve the outcomes they are designed to achieve.
  Ultimately, services need to do the basics right, which means they need to deliver upon the outcomes they seek to achieve. This is particularly important in acute situations involving vulnerable users.
• Offer support to people who find a process hard to follow.
  Sometimes we need more personal, tailored support in order to access a government service. There should be options for users to get in touch, to get help if they’re struggling to access what they need.
• Offer alternative journeys to people who prefer not to — or cannot — use the default.
  As an example, this might include a paper-based form for people who cannot access an online version, but the exact nature of alternative journeys will depend on user needs.

These thoughts aren’t mutually exclusive and completely exhaustive, but they’re not bad for a Wednesday morning. We’re really keen to hear more ideas from the user-centred design community on this topic. What else would you add to this list? What have we got horribly wrong? We invite you to share your thoughts in the comment section below, or in our public Miro board here.

(A little note — we’ve got loads of colleagues across projects and teams who have influenced these thoughts. You surely know who you are).