Invisible services and how to fix them

Picture the scene….you’re talking to Bob from finance about services.

You’ve talked for at least 4 minutes without being interrupted. Things are going well...Too well?

You’ve discussed why user research is important and it seems to be sinking in....until it comes, as inevitably it always would, the moment when he asks what, exactly, you mean by a service.

You take a deep breath and say what you came here to say. A service is something that helps someone to do something. It can involve multiple actions or parts that are provided by multiple teams or organisations, our users define our services by what they’re looking to get done…Silence fills the room.

The previously calm and interested Bob looks at you like a vulture assessing its dinner. Surely….surely, you’re not suggesting that the ‘service’ is bigger than his beloved e-portal? His e-portal of dreams, the glorious, immortal e-portal? Sure, it has its issues, everyone knows that. But the suggestion that it is just a small and insignificant speck in a much larger user journey (and an annoying speck at that) is frankly, laughable.

His ‘product’ is perfect, the ‘system’ works well. The ‘process’ is faultless. Why, oh why do you have to complicate things with this word, ‘SERVICE’?!

Most organisations cant see services

To design something you have to - at a bare minimum - believe that it exists. And this is the problem we have with services.

Services are invisible by their nature. They help our users to achieve an end goal, but they are more than the sum of their component parts. Services are also made of the connections between the products, systems and information we interact with.

These connections join a patchwork of products, systems and processes together to help our users reach the outcome they set out to do; like the return code generated after buying something, the medical records transferred to the next consultant you’ll see, the appointment that’s added to your calendar. Like the oxygen swirling all around us, into our lungs and around the room we’re sitting in, these connections are invisible and unimportant, until they're not there.

This is the eternal paradox of service design. Before you can contemplate making a service better, you have to play a seemingly endless game of Schrodinger's Service. If your stakeholders can't see the service does it really exist? And if they don’t think it exists, how are you supposed to design it?!

Most services are ‘designed’ by accident

The consequence of this invisibility is that most organisations focus instead on the ‘tangible things’ they can see; the ‘products’, the ‘systems’, the ‘processes’....and the portals they provide. Meaning that most of the time, ‘service design’ is an accidental byproduct of a myriad of decisions we make about those products - from technology compromises, political trends or personal taste - rather than a conscious, deliberate act where we decide exactly how a service should work.

But you know who can see services? Users.

If we don’t design services, we force our users to

Our users see the connections between these products, systems and processes because they’re the ones who have to create those connections themselves. Like downloading a form from one organisation in order to post it to another, cancelling an account only to open another one because they have changed addresses, or writing an email to confirm something they’ve already told you over the phone.

By not consciously designing our services, we leave it to our users to do it for us.

Our users become ‘meatlinks’. Human beings doing the job your service should be doing of connecting the disparate systems, processes and products involved in that task into something that enables them to do the thing they set out to do.

This means that as the creators of our services, our users, are often the only ones who actually know what those services are or how to use them.

To actually design services, rather than forcing our users to create them for us, we need to see services as real things that can and should be designed consciously. Because unless we believe a thing exists, we can’t design it in the first palace.

Service design = making the invisible visible

This means that your most important job as someone who wants to improve a service is to make the invisible visible to the people who are providing it. To shine your magic CSI wand over the crime scene that is most services and show the glowing blue pathway that users take between your products, systems and processes in order to create the service that will help them to achieve their goal. To show that services, far from not existing, are all around us, waiting to be consciously designed.

So how exactly do you do that?

How to make services visible

There’s no right way to do this, but here are some things that work

1.Map all the services

The likelihood is, the service you’re working on right now will be bigger than your organisation thinks it is. Your user wants to open a bank account for example, but the team you’re working with is focussed just on identity verification.

Because of this, at some point you’re likely to be asked something along the lines of “so what *isn’t* part of this service?” and you’re going to need an answer.

Since many of your services will be interconnected and their boundaries blurred, there’s no way that you can have a conversation about one service without understanding where it fits with all of the others, so first things first, find out what your services are.

This can be tricky to do. It involves user research, but before you get lost in an enormous existential crisis, first audit of all the STUFF; content lists, IT system diagrams, CMS indexes can all be helpful. Try to group the transactions, forms, content, processes and systems you find into rational verb based groups, like ‘learn to drive’ or ‘book a holiday’ or ‘open a bank account’.

You’ll find some systems and content are used by multiple different services and that’s ok, services are made of small pieces loosely joined after all, and that means those small pieces don’t have to appear in just one service.

This evergreen post about mapping all the things at the UK Home Office by Kate Tarling is a good place to start on your journey of mapping all the things.

2. Validate your list of services

The only person to tell you if your assumption about your list of services is right is your user. But speaking to them directly about their mental model of services can be tricky since your user is unlikely to think about what you do as a service. There is however, one question you can ask your users to try and validate whether your understanding of what the service is matches with theirs and that is - ‘what are you trying to do?’

Even though they might not know it, your user defines your service by what they’re trying to do, so this is where you’ll need to start. You're looking for a verb, but not just any verb - the thing they think exists as a service, or the thing they’ll think to ask for or search for.

Not everyone’s answer will be the same, but you can work out something that fits most users. And if you have big variances, who’s to say your service cant have more than one start point?

This blog post I wrote back in June about what services are is a great place to start if you’re unsure of how to define your service

3. Make your users visible to your organisation

As soon as you start to share your list of verbs to others in your organisation you're likely to face a tidal wave of questions: ‘how did you come up with this list?’ and more likely ‘who the hell are you to start defining what we do!?’ in order to avoid these awkward situations it's best to see the task of defining your services as a collaborative exercise, between your users and the people who are providing the service.

First though, we need to make the perspective of these users visible to our organisation. This is often easier said than done, as we can see in this post on why services fail.

The only way to do this is through exposure; getting your colleagues and stakeholders to see your services from the perspective of your users. That means helping them to attend the user-research you’ll do around your services with your users.

4. Make your services visible to your organisation

Your next trick is to help other people to see what you can see. You’ll probably have an ENORMOUS list of services. You’ll have gone through a million iterations of your categories and have started to categorise your socks as a bit of light relief. But it's one thing to see the truth, and another thing to help other people to see it too.

Don't forget that this is a learning opportunity for the organisation to not only redefine the services themselves but to shift their perspective on services more generally. Create a predictable schedule for your work so that everyone knows what’s happening and when they can input their thoughts. Show the feedback of your users to everyone around you and make it clear that the definition of these services comes from them.

Helping your organisation to see it’s services is one of the many, important roles of a service designer. If you want to know more about becoming a service designer, or working as a service designer in an agile environment our 3 day Agile Service Design course can help.