Hanna Serednytska's Key Ideas from Good Services
by Louise Downe

The service must be able to be found by a user with no prior knowledge of the task they set out to do. For example, someone who wants to ‘learn to drive’ must be able to find their way to ‘get a driving licence’ as part of that service unaided.

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.

Without understanding what our users are trying to achieve, and reinterpreting our services in language that our users can understand, we often place users in a situation where, to find something, they need to know exactly what they’re looking for.

The less you know about the situation you’re in, the support available to you or what you should do, the harder you will find this search. Needless to say, even the most patient people wilt at the prospect of this almost impossible task.

Rather than using the words your organisation uses to describe the tasks it has completed, try to find out some of the words your user would use to describe what they’re trying to achieve.

1. Avoid legal or technical language
2. Describe a task, not a technology
3. Don’t use acronyms

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.

Purpose of your service =

what your service does +

why it does it +

how it does it +

who it’s for

Clearly express what the service tangibly does for your user. Be factual, avoid marketing promises. Stick to the functionality.

What outcome will it achieve for the user?

Sometimes how your service works is almost as important as what it does.

Who is able to use it?

How is it paid for?

Is it a subscription or a one-off purchase?

How quickly can you do the thing you’re offering?

What is it about the way your service works that makes it quicker or more convenient for your users than any other?

Are there any other benefits to your service besides basic convenience?

Is your service sustainable or funded/made in a way that benefits society at large?

This will probably be obvious to your user if you express what the service does and how it does it well enough, but you’ll also need to explain that it’s not possible to use the service to users who aren’t eligible or suitable for the service so that they can be moved out of the journey as soon as possible.

Possibly the most crucial of all: make sure you explain to your users why your service exists and what outcome it will achieve, both personally for the user and for society.

Clearly communicate this to users – through things like the service name, description and even the interface of how it works.

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.

How long something will take to complete, how much it will cost, whether they will be contacted and what else they might need to do after using your service are all things that a user needs to know to make a decision about whether or not to use your service.

Whether that effect is big or small, knowing what to expect helps people to plan and take control of their situation. It gives them power – and in some cases the ability to make another choice if what you’re offering isn’t going to work for them.

Most people base their expectations on past experiences, so if another company in another country has done something, the likelihood is someone is going to expect the same of you at some point.

Universal expectations. These are the things about your service that are fundamental to what you’re delivering and are universal to almost all users because other similar services work in the same way.

Assumed expectations. When someone doesn’t know what to expect, then an assumption usually takes its place. These are usually assumptions that are easier or more convenient for the user. 

Outlier expectations. These are the things that only some users might expect, based on a previous experience of a similar service elsewhere, and can very often be based on a better experience a user have had.

You won’t need to explain universal expectations to users when they sign up to your service. You will need to monitor these closely, though, because if any universal expectations aren’t met at any point, they will have the most severe effect on your user.

Assumed expectations are  the things that are the most important to explain upfront to your users, because although they’re obvious to you, they won’t be to your users unless they’re experts.

Outlier expectations. You won’t need to consider them in your service now, but you do need to watch out in the future.

A good service helps the user to achieve a goal – be that start a business, learn to drive or move house – in as much of a seamless stream of events as possible. This starts from the moment that a user is considering doing something to the moment they have achieved their goal, including any steps needed to support the user after they have reached their goal.

What your user expects from your service when they arrive at it is very often not the same as the service you provide.

What’s important isn’t the scope of what you provide, but whether or not the part of the journey you provide helps your user to reach their ultimate goal.

What it also shows us is that when we try to solve one small part of a user’s problem with one small slice of a service, we often don’t achieve the results we set out to achieve.

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

1. Understanding what your user is trying to achieve.
2. Get a good understanding of who else delivers parts of this service and how they relate to your organization.
3. Look at your organization’s ability to deliver all of this service; if this isn’t feasible, define what a rational scope for your part of that end-to-end service will be.
4. Consider which part of the service it makes sense to deliver first. Start small and build or improve in increments.
5. Look at how data gets shared between the organisations delivering this service, are there things you could share that make it easier for your user?

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 conform to that custom. But be mindful that not all customs benefit users – some have been put in for the benefit of the organization running the service rather than users. Avoid customs that negatively affect your users or those that are inefficient or outdated.

There is a delicate balance between working in a familiar way, and breaking out of this to set a better way of working.

Try to do something new without properly testing it with users, and you risk creating a ‘new’ way of working that is unusable because users have no prior experience of it.

Equally, sticking with a way of working that doesn’t work for users just because that’s what everyone else does can be just as damaging.

Crucially, though, changes to expected ways of working in your service require a critical mass to be usable by all users. The bigger the shift from the norm, the more ubiquitous this will need to be for users to become familiar enough to be able to or want to use your changed service.

1. Research how your competitors work and look for patterns in what they do.
2. Understand if there is an easier, more intuitive or more effective way of doing what you’re doing.
3. If there is, test it to understand how different this is from your users’ existing expectations of how your service might work.
4. Make sure that any changes you make are intuitive.
5. Share the changes to the way your service works with others so that your pattern can become ubiquitous.

A service should not work in a way that assumes any prior knowledge from the user.

We need to think about:

1. How does someone know your service exists when they need it?  Does your user know your service exists?
2. How do they find it once they know it’s there? Can they find it using their own logical searches for what they’re looking for?
3. How do they access and use it? Does the service clearly explain what it does? Does the user know what to expect and what is expected of them?

The service must work in a way that does not unnecessarily expose a user to the internal structures of the organization providing the service.

Separation of data. Review what data flows through your end-to-end service, who collects it and who has access to it.

Incompatible processes. This can be one part of a journey that takes a certain amount of time, and doesn’t match up with the deadlines of another.

Incompatible criteria of use. Try to map out all of the mandatory requirements in your service and see if these are consistent across all touchpoints.

Inconsistent language. 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.

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. This may mean occasionally slowing the progress of a service in order to help a user absorb information or make an important decision without having to contact you to help them.

Services are made of small pieces, but they are more than the sum of their parts. How many steps your service has and how quickly your user goes through them is often as important as what those parts do.

The number and pace of the steps within your service can be designed in a way that best suits what your user wants to achieve, rather than just evolving from the conditions they’re in.

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.

Don’t just design the steps of your service, design the space between them. 

1. Review where decisions need to be made in your service. If you have too many steps, look to merge these into fewer steps to make the journey simpler for your user. 
2. Allow users to focus on one task at a time. Users need to be able to focus in order to make a decision. Look at areas of your service where multiple decisions have been merged into one step and consider breaking these down.
3. Think about how fast or slow your steps need to be. Look at how big the decisions in your service are, or where your user might need to be more focused and ‘present in the moment’ to experience something.

In reality, although there are points in a journey where failure has more of an effect than another – being able to complete a service from start to finish is far more important than having a great experience in one moment, then not be able to complete the rest of the journey.

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.

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.

However, consistency is very often mistaken as uniformity, where we aim for a service experience that is exactly the same across all parts of the journey, all channels, and between different users.

When users need a solution to a complex problem, it’s a human, tailored response that they need, not a scripted bot. But responding and working with a user’s individual circumstance with freedom requires empowered staff.

1. Consistency across user journey. Ensure that you think about the minimum viable service, and make a plan to ensure that there are no gaps in your user’s journey that have been neglected.
2. Consistency in each channel. Make sure you’ve tested each channel from start to finish with your journey, and have tested what the transition is between these channels.
3. Consistency over time. Organise regular reviews to make sure your service is tested from every angle on a regular basis.
4. Consistency between users. You may offer premium versions of your service, but make sure it is clear why you do this.

A service should direct all users to a clear outcome, 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.

Some of these dead ends will be for legitimate reasons – for example, a person who isn’t qualified for a place at a certain university won’t be able to get a place at that university.

But some happen because we failed to account for a particular situation a user might be in – for example, they might not be able to provide proof of their previous qualifications because they qualified a long time ago.

This is the one ‘intentional’ dead end your user might face – where someone has a situation that simply doesn’t fit your service. For example, someone lives too far away for you to deliver to them, or doesn’t meet the criteria your service has set out for another reason.

Although your service might not suit them, try to deal with these dead ends as elegantly as possible, providing onward links to relevant support where possible. Just because they aren’t able to use your service to reach their end goal doesn’t mean your service isn’t part of their journey to be able to do this.

Sometimes dead ends happen more gradually than simply giving someone no option to continue. Services that are very simple for those on the ‘happy path’ often hide complex and hard to navigate side routes that don’t necessarily ‘stop’ a user from doing something, but slow them down to the extent that they can’t get what they need to do done.

If your service has complex elements further down the route, it’s best to explain these at the start, rather than giving users the expectation that your service is simple all the way through.

Common barriers within your particular service

1. The ability to remember long numbers
2. The ability to follow complex instructions
3. The ability to remember dates, times and appointments
4. The ability to get somewhere physically
5. The ability to get somewhere or do something during working hours
6. The ability to read a language fluently
7. The ability to read PDFs or access ‘non-accessible’ digital services

Just as you have done with the things you presume your user can do, the first task is to identify all of the things you assume your users will have access to at any given point in their journey, and analyse what happens when they don’t have access to these things.

As a rule of thumb, you should try to minimise this list of absolute requirements to as few as possible while ensuring your service is secure.

• A phone number
• A bank account or credit/debit card
• An email address
• Official identification, such as passport, driving licence or state-issued ID card
• An address, or proof of address
• Any of the above, in the country that you’re operating in
• Any unique identifiers your company uses to identify that user, for example, policy numbers, account numbers, booking references

Many of our stereotypes about who has and who hasn’t got access to the internet are simply wrong. However, much more damaging is our presumption that access to the internet is stable and predictable.

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.

This is why we need to go beyond thinking about accessibility, with all of the inherent biases that come along with creating a baseline of ‘normal’ versus those with ‘access needs’, and start to think in terms of ‘inclusion’ of a full spectrum of needs instead.

With services, it’s also important to consider how all of these needs will affect each user across each channel, rather than just looking at the experience of a digital service.

1. What they can do. These might be things like the ability to see, read, talk, hear, remember things, get somewhere physically or cope with loud spaces.
2. Who they are. These things will be things like someone’s ethnic background, gender identity, sex, sexual orientation, age or religion.
3. What they have. These are things like time, money, transportation, family and friends, but also self belief, civic literacy and education.

Inclusion is a scale that progressively means that your user can not only use your service but also feel safe, welcome, and, – importantly, use it in a way that makes them feel equal to all other users who might need to use that service.

It’s equally important to remember that inclusion doesn’t always mean making everyone do something in the same way. Sometimes, different users will need a different pathway through your service because it works better for them.

The service should encourage safe, productive behaviours from users and staff that are mutually beneficial. For users, the service should not set a precedent for behaviours that may put the user at harm in other circumstances – for example, providing data without knowing its use. For staff, this means they should not be incentivised to provide a bad service to users, for example, through short call-handling time targets.