How to design services for government; a way to do things better

As the largest public service provider in New Zealand, the Government is in the privileged position that every kiwi needs to access their services at some point.

Essentially, government services fall within three categories depending on the problem they are solving for people:

  • Asking, eg What do I need to apply for a driver's license?
  • Applying, eg Apply for a driver's license.
  • Informing, eg I've changed my address.

Unfortunately, most of the public services are still based on an organisation's processes. Instead of offering the option to apply for a service, we are often telling to people 'here is a list of forms'.

Even if a customer knows exactly which form to complete (and hopefully not download and print), they will likely still be hindered by a set of unfamiliar questions such us What is your NHI number?.

If the required service is provided via a sequence of interactions with more than one department, the customer will likely have to repeatedly answer the same questions.

Sometimes, a customer has to answer questions irrelevant to their application, only because the organisation wants to capture demographic and statistical information, and somehow haven't found a better way or moment to ask for this.

If a customer has to use it and there is no alternative, why should we invest time and effort on designing a better way to provide services? In my view, because it's the right thing to do and we are all users of these services. But if that is not enough, here are a few more reasons:

  • Increase the productivity. The more times a customer spends on dealing with a public service and their processes, the less time they will spend on productive activities
  • Mitigate brand impact. As customers grow frustrated in dealing with public systems, their stress levels increase and a sentiment against the organisation grows, generating a negative impact on the brand.
  • Organisation efficiency. If a customer doesn't submit the correct information, it can take a long time to process their request. It means that the organisation will likely have to contact that person to ask for the right information and re-process it.
  • Organisation effectiveness. If a customer doesn't understand the process, they will likely call the organisation. This consumes call centre resources, shifting their focus away from solving more critical customer issues. These employees will also have to deal with customers frustrations generated by the process.

Service design is not rocket science. It's, in essence, the observation of how we are doing things, what is working well, what can be improved? And then improving it!

When we carefully observe how things are done, we can match our services with the way customers use them, and then identify the natural moment to interact with the customer using the right information.

If we are doing things well, it should become a principle. A customer should never know that they are interacting with a different department within one organisation, or that the service has been designed by different people.

When we discover things to improve, we should be able to quickly create a solution and immediately validate our thinking by testing to ensure we have solved the problem. If it fails, we want to fail fast so we can iterate and improve.

Observing real customers and matching services against their needs is made easier and effective by applying simple customer research and journey mapping techniques.

Pleasant and consistent experiences are achievable through building a framework that any design and development team can use.

Prototyping and usability testing is a great way to make things better by failing and improving concepts fast.

 


 

Customer Research, Journey Mapping, Services Framework, Fast Prototyping and Usability Tests are just some of the techniques that can be applied in the process of designing better services.

If you need to apply any of these techniques to improve your services, have a look to our UX and Design services.