Good Services

Richard Oliver published the widely known ‘Expectation Confirmation Theory’. Summarised simply, it states that customer satisfaction is the result of a comparison of our expectations with our experience. If they match, we’re satisfied; if experience prevails over expectations we’re delighted; but if expectations outweigh experience, we’re dissatisfied.

In 1984, Professor Noriaki Kano published the ‘Kano Model’, a theory for product development and customer satisfaction. It describes three main factors: basic factors (‘Must-be Quality’) that, similar to hygiene factors, do not contribute to satisfaction but cause dissatisfaction if missing; performance factors (‘One-dimensional Quality’) that can contribute to dissatisfaction when they’re missing, but also to satisfaction when they are implemented well; and excitement factors (‘Attractive Quality’) that only contribute to satisfaction, but don’t cause dissatisfaction when they’re missing.

services exist in the background by their very nature. They are the things that connect other things, the spaces between things–such as choosing a new car and having it delivered or booking an appointment at your GP and being successfully treated. We barely notice them until we encounter something that stands out as good or bad.

What unites all services is that they help us to achieve a goal, however big or small it might be. The parts of a service might be provided by a number of different organisations but, to a user, a service is one continuous set of actions towards that end goal, regardless of who is providing it.

we often don’t rely on a new technology until that technology is ubiquitous. Since we don’t have one 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. This means that services often keep a channel as a back-up long after the technology has ceased to be the main means of access for users, which in turn leads us to try to run the same service in multiple channels, without thinking of how that service would work natively in its new environment.

Services in the internet age are not only defined by the user who’s looking for them, but composed of ‘small pieces loosely joined’ as David Weinberger predicted in 2002. For example, when you’re embarking on the goal of buying a house you might find that you need to complete several very distinct steps in order to be able to achieve it–like hiring a surveyor. Those steps themselves will then be broken down into smaller tasks. For example, when getting a survey done, you might need to first book a time for that survey to be done, then pay for it and review the final result. In that way, each service is broken down into steps, and each step into a series of tasks.

Individually, these can all seem like accidents, ‘just the way the service works’. But at some point, they were all conscious decisions that add up to a service that neither meets the needs of individual users nor the goals of the organisation providing it.

A good service is easy to find

A good service clearly explains its purpose

A good service must clearly explain what is needed from the user to complete the service and what that user 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.

San Jose residents were frustrated because the digital service didn’t let them know how long it would take to get something fixed. By not setting expectations for users, the team had set their service up to fail.

Nothing is as effective as making sure that your service is as simple as possible to use and works in a way that is expected, but if this isn’t possible, and sometimes it isn’t, make sure that you identify your assumed expectations and explain as clearly as you can (at the point that expectation becomes important to your user) what they should expect.

Be very wary of explaining to the point you end up requiring your user to educate themselves in your process before they start. Doing this puts all the responsibility on the user, and means they’ll either not bother to read your carefully written instructions (when was the last time you read a manual from cover to cover?) or give up on your service entirely.

So, to design a good service, always meet your users’ universal expectations, try to reduce as many of their assumed expectations as possible and keep a firm eye on outlier expectations so that you’re ahead of the curve when some of these become universal.

Often, the perceived cost saving we think we will achieve in providing a smaller part of a whole service is outweighed in the number of people who have to provide additional elements of their service to pick up the pieces. Our service might still be cheaper, but someone is picking up the bill elsewhere.

Krug says: ‘If you can’t make something self-evident, you at least need to make it self-explanatory… It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice’.

Your users may be first-time users, but they will come to your service with a set of assumptions, expectations and even superstitions that will need to be corrected, adjusted or reinforced, depending on their accuracy. The first step towards this will be to understand what expectations your users have in the first place. This will mean doing user research to find out. Once you know and understand the expectations, there will be some that you need to actively contradict, and those you need to design into your service. Only you can know what these are, but as a general rule of thumb try to consider what expectations are good for your users, your company and society at large. If they aren’t, they will need to be something you proactively change.

review what data flows through your end-to-end service, who collects it and who has access to it. Try to spot places where the same data is collected multiple times and not shared and design your end-to-end service starting with the data, rather than as an afterthought.

Inconsistent language between different organisations or parts of an organisation might seem like a minor issue, but when it comes to asking users to reference certain documents or artefacts that they might need to continue a process, not sharing the same definitions between parts of your service can be hugely disorientating. Take a look at all of the nouns in your service–documents, processes, activities or things that a user needs to do–and look at how they’re referred to in different areas of your service. Create a taxonomy of the things a user might need to refer to and make sure that these are the same in all areas of your service.

Conway said that if an organisation was made up of separated, isolated software engineers, then they were likely to produce separate, isolated services as a result. This separation wasn’t a problem, he said, so long as the designers of each of these pieces of software were able to communicate effectively with each other. This was because: ‘each piece of software cannot interface correctly with each other unless the designer and implementer of one piece of software communicates with the designer and implementer of another’. Crucially, this meant that ‘the structure of a software system necessarily will show a similarity with the social structure of the organisation that produced it.’

Conway said that: ‘because the design that occurs first is almost never the best possible, the prevailing system or concept may need to change. Therefore, flexibility of organization is important to effective design.’

Conway’s law show is that, above anything else, communication is the one thing that either makes or breaks your service’s ability to provide something that works for your user. Rather than looking at the ways we can collaborate and work together better, we fixate on getting the perfect structure that will allow everything to work perfectly with minimal crossover. This often results in a proliferation of separate business units, organisations and sub-brands to deliver parts of our service ‘efficiently’, when what we are really doing is sacrificing communication across the whole journey for a marginally easier way of delivering a single bit of a service.

most organisations are now in a constant state of reorganisation to achieve this mythical perfection, when in reality the most important factor, as Conway says, is to communicate effectively, regardless of your structure.

When thinking about how many steps your service needs, there is a simple rule: the number of steps in your service should be equal to the number of decisions your user has to make, no more and no less.

Any situation that relies on the work of multiple people to deliver something can be understood as a kind of chain, with weaker and stronger parts that add up to overall success or failure. One weak link in this chain, and a business doesn’t thrive as much as its competitors in other markets that have access to these things.

When we build a minimum viable service, we should be aiming for a service through which most of our users will navigate to achieve the goal they set out to do. Starting from the point of view of a minimum viable service rather than ‘product’ forces us to think about which areas need to be in place before your service is usable.

The digital channel might be your main route of interaction with your users, as might your phone or face-to-face service–but your users will interact with your service in multiple ways. Make sure you’ve tested each channel from start to finish with your journey, and have tested what the transition is between these channels.

when new layers of technology get added to a service, we rarely turn the old ones off. This has the effect that each new technology adds an additional channel to our service where some services might exist as post, phone, face-to-face and chatbot simultaneously. When done well, each new technology is treated as a progressive enhancement on the last, meaning that when a user is unable to access a service using one technology, we can rely on the one that came before it to enable the user to reach their end goal. We can see this as a kind of a progressive enhancement in reverse, or a progressive degeneration of the service. At some point, this means that some services will need to operate what we can think of as a ‘service of last resort’–where, because a user’s circumstance is so complex, the service needs to be performed entirely by a human with nothing but their own judgement.

Think carefully about what pieces of information you use to anchor the identity of your user within your service–their name, gender, age, location, address and phone number can all change. Your service should respond to changes to these areas as much as it does to indirect changes.

2Make 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 those that don’t, think about how they will affect the other aspects of your service.

that if you can’t explain why you came to a decision, it’s almost impossible for staff to change that decision, or for users to appeal it.

However small that decision might seem to you, it has the potential to change how much your user trusts you. It’s how that decision is made, not that decision itself, which leads your user to either trust or not trust you. Transparency of decision-making shows how a decision will affect a user in advance, and gives them the ability to take control of their situation, change their circumstances, go elsewhere or challenge your decision. For staff too, transparency means that they can override and challenge a decision, but only if they know how it works.

60% of that cost was spent on calls and casework. Diving deeper still into these numbers, roughly 43% of these calls were status-chasing calls, 52% were questions about how to do something, 5% were complaints, but the smallest number by far were calls to do with complex cases, at just around 2% of total calls. In essence, most human contact to our services is unnecessary, but generated by badly designed services that mean more people are entering the system than necesssary (generating delays to the service and subsequent status-checking calls) or are confused about what they need to do to achieve a certain outcome–the vast majority of which could be solved with clearer service design.

It’s important to get the balance right of human to digital in your service. Getting the balance wrong can happen in both directions. The more humans that are involved in providing your service, the more expensive it becomes to scale, meaning that too much human contact and not enough automation can artificially incentivise your organisation to focus on users who exhibit only the most extreme cases.

Incorporating human decision-makers into your service is vital, as we’ve seen. But it has to be used proportionally to the needs of your users and the service at hand. Too much contact and your service can disproportionately favour a small group of users over a wider selection, or prove to be unsustainable. Too few and your service is likely to not meet the most complex needs of users.