Using Systems Thinking to Design Better Services

When creating new services for clients, we very often don’t delve deep enough into the organisation that delivers the service. Service solutions are often limited to pragmatic improvements that lie directly in the customer experience, what many consider ‘the art of the possible’. But by combining classic service design and user journey mapping techniques with notation from Systems Thinking, we can go deeper into understanding WTF’s really going on inside our organisations.

Get in touch if you want to discuss more.

Consider a few examples of customer issues that people face every day;

Monique has just started her first full-time job. She calls a mobile telco to set up a pay-monthly contract. After 20 minutes of sharing her most personal information, the call is dropped. When she calls back, she’s made to start again because the telco’s IT systems don’t allow her to pick up where she left off.

Andrew is in the queue to pay for his shopping at his local supermarket. He’s embarrassed to be told that his card has been refused. He calls the bank to find out why. There’s been a spate of frauds committed where the words ‘Curry’s’ appears on bank statements. So when he had previously ordered something from Curry’s online, Andrew’s card was blocked by a fraud detection algorithm. To rectify it, he must be put through to the Fraud Prevention Unit to unlock his card by talking through the last 5 transactions.

Anji has recently moved house. She walks into her local bank branch, queues up, produces identity and verification, fills out a form and shows proof of her new address. The form is then passed on to their operations team who manually keys the change into 4 different IT systems. Each of the systems have different verification rules and a different number of input fields. Months later she notices that she’s no longer receiving mail from the bank. After calling them, she realises they’ve misspelled the name of her street.

These kinds of transgressions rarely have clear-cut causes. If you’ve ever spent time investigating these kinds of issues, interviews can be fraught with blame. It’s easy to imagine that somebody somewhere has been a fool and not done their job properly. Generally, these kinds of issues have complex, interrelated causes. One could argue that the rigid technical infrastructure of internal IT services is to blame. Or you could say it’s a culture that values security theatre over customer experience. Or a lack of investment in technical infrastructure. Or maybe it’s because the IT systems and processes just weren’t procured or created to support the features that the service now needs to support. Usually, these systems are procured less for their ability to perform a flexible, interoperable set of procedures and more for their low cost of ownership. The services have evolved and now behave in a way that just about makes ends meet. They’ve evolved to work in a particular way, but now they’ve reached such a point where everything is frozen in time. People keep paying for the service, so it’s hard to make the case for change. And few people are incentivised to make the case for change because livelihoods depends on everything staying just the way it is.

These kinds of issues crop up much more often among larger, often monolithic organisations where the creative, daring, entrepreneurial leadership that created the organisation is no longer there. Here, the cost of updating technical infrastructure is far higher than that of the limber startups deploying code multiple times a day with their release notes written GIFs or pure emoji. Cycle times for code deployment at large organisations is often months, not days. I recently worked with a large financial institution that proudly announced it’s new Rapid Deployment Process, which makes it possible to deploy once a month- a huge improvement on the previous annual deploys.

The cause of the these example problems aren’t to be found within the customer experiences themselves. Plenty of managers would like to think that’s the case. It’s easy to blame customers and front line staff. Organisations are often blind to these kinds of issues, unless they crop up in complaints data, NPS verbatims or leadership and employees experience them first hand. The root causes of these kinds of problems are spread throughout the organisation — in the operational or cultural layers. In other words, these kinds of problems are systemic.

Machines, cogs and teeth

It’s a cliche to talk about large organisations as being like machines, but it’s true. Though unlike machines, they have organic capabilities. Each part of the machine is capable of syphoning off resources of the machine to create new parts or destroy parts of the machine that it’s responsible for. A driver of a Land Rover can install spotlights with halogen bulbs to replace the old dim lights if they like to drive a lot at night. Sadly, Land Rovers aren’t yet able of growing new and headlights.

The customer sees just the surface of the machine, the handles, the buttons and the dashboard. Unlike a car, they don’t get to peer into the engine and have a poke around, inspecting the chassis. The same goes for management, service designers, product managers etc. We’ll often fall short of getting our hands dirty in the oily parts of the machine itself. This is often because we don’t have to. Many service design engagements can make a decent enough, short term impact by tinkering on the surface — changing the oil, giving it a polish, changing the headlights or adding a few racing lines.

Peering into the machine is exactly what we can and should be doing to help organisations to make the changes required to deliver better services. This is especially the case since many root causes of customer experience problems lie in some very tricksy areas, for example;

• lack of integration between legacy systems
• lack of time permitted by senior management to let engineers refactor code and pay down technical debt
• procurement logic that isn’t aligned with business strategy
• misalignment of incentives of sales, marketing, product and customer service departments
• unclear, non-existant or just plain crap strategies
• over-investment in one very public aspect of the business while starving another, more quiet but vital part
• abandonment of projects before achieving intended outcomes

Many service designers understand this and are approaching this challenge in different ways. Livework studios have recently started to employ ‘business designers’ to partner with service designers — Joel Bailey was talking about this a while back. FutureGov have something called a ‘change team’ that practices organisational design. And at many large institutions, people that once called themselves business architects are moving away from PowerPoint and picking up the Sharpies and the Post-Its, creating organisational design teams and engaging stakeholders collaboratively to workshops. All good stuff. This is perhaps why we’ve seen so many acquisitions of service design organisations by large accounting and management consultants of late— Seren by Ernst & Young, Fjord by Accenture. Service Design, as a practice area has the ability to transform organisations, providing with can get our hands dirty and we (to borrow Joel’s words) “Go deep”.

Systems thinking and service design

Service designers can facilitate groups to use systems thinking to help stakeholders better diagnose the causes of customer experience problems. Once the organisation is understood, prototyping can be used to design new organisational structures that support a better customer experience.

“Service design is great for understanding the as-is state, but Systems Thinking is better for understanding what’s really going on.”

This is paraphrased from a client recently. I agree with the idea in principle. A common output of service design will often be something that either communicates the ‘as-is’ or the ‘to-be’ state of the service. We may go into depth on certain aspects, such as a brochure, a training manual, an app concept or a point-of sale piece. But really, service design will not tend to go into great detail about the causes of problems identified. But as I’m going to outline here, it can and it should.

I like this definition of service design from Louise Downe, Head of Design for GDS in her recent post ‘What we mean by service design’.

“Service design is the activity of working out which of these pieces need to fit together, asking how well they meet user needs, and rebuilding them from the ground up so that they do.”

The “bits” referred to here are bits of government.

Now, if you want to get to the bottom of what’s really going on inside a large organisation (like government), systems thinking is pretty helpful. If you’re still wondering what I mean by systems thinking, don’t worry I’ll come to it. This post is essentially about what might happen if service design and systems thinking got friendly and made a baby.

Front line coping

Most services are not designed end-to-end, top-to-bottom like a service designer might. In reality, away from the whirlwind of Post-Its and Sharpies, the sketching workshops and blueprints, most services have come to be with little more than can be described as ‘front line coping’.

“Things get designed, whether you design them or not.” Maggie Breslin, Mayo Clinic

Services evolve over many years with bits bolted on here and there, very often with little thought for how the end-to-end experience looks and feels to customers. In particular, there’s often little consideration of the unintended consequences.

“that’s kind of a problem with consulting… if it’s not a strategic partnership, consultancies just create the next version of problems for the next team to solve” Jonathan Kalinowski, in the Practical Service Design Slack Channel.

The awesome quote above sums up why services deteriorate — silo’d, short-term thinking. Frontline coping is a quick fix and very often it works in favour of the service provider, not the customer.

The default method is simply front line staff and their managers coping with demand as best they can. Staff and managers tend to get by year-by-year on the budget allocated to them. Sometimes they’ll over-optimise a particular area, sometimes they’ll make temporary fixes that cause problems elsewhere. But unless there’s a concerted effort to redesign the operations to meet with expectations and needs of customers, the design is emergent. Emergent designs are more likely to serve the needs of the individuals that conceive of the solutions more than they serve the customer. The service itself is simply coping with the demand that’s thrown at them. Without looking at the service holistically and indeed, how the service is delivered operationally, we’re only every optimising locally.

So, in summary, service design is supposed to offer solutions to improve services for customers. These shouldn’t be short-term, surface fixes, they should be long-lasting, comprehensive solutions that begin by helping groups to thoroughly diagnose the causes of problems and where to intervene to solve them.

Service blueprints

Service blueprints are generally used both to communicate future states or diagnose current states. This isn’t to say that this is the only tool service designers use, but it’s very much a favoured method. It’s a powerful tool for collaboration, for having a shared view of the typical customer journey and how the organisation supports and responds to that journey.

Your technique may vary, but the horizontal axis is time, while the vertical represents some form of ‘depth’ to the organisation, with customer touchpoints at the top.

Here’s an outline of a service blueprint;

In essence we’re saying (in blue);

Understanding the customer experience as a series of touchpoints is one important part of the puzzle. We’ll very often go to town on the bit at the top - service safaris, observations, contextual enquiry, depth interviews, usability studies, paper prototyping, experience prototyping etc are all great techniques for learning about customers and what they need.

And likewise, we can use some of these techniques to understand what’s really going on within the organisation at the employee level. Workshops, depth interviews, cultural probes etc are great ways to understand how employees think and feel about the service they provide.

It’s common to see a lot more about the customer experience than the underlying operations that deliver the service;

We tend to take a longer, harder look at the customer than we do at the operations layer.

Here’s another approach, where we can track customer sentiment over the lifetime of the journey;

This is a good way to identify where services might benefit from some improvements. We could probably address each of the red dips and we’d have a vastly better service than we had previously.

You can also add supporting evidence in the form of quotes from customers. These can be really powerful because it’s not often that leadership from the organisation will have such a breadth of insight in one place. Quotes can make those insights real and memorable and play on the more emotional aspect of the decision making.

Here’s a nice example from Smashing Boxes’ Natasha Barrett’s post ‘Being a Service Designer at a Digital Product Agency’.

But very often, this is as far as we tend to go with blueprints.

WTF’s really going on?

Many standard blueprints generally only list the internal systems, employees or processes that are involved at each stage. But without really peering into the machine and getting our hands dirty in the organisation, how can we get to the bottom of why the problems occurred in the first place? Standard service blueprints don’t help us understand and see WTF’s really going on. They don’t help us see the systemic issues. There’s often very little in terms of diagnosing why the customer experience is the way it is.

Let’s say, for example, our blueprint is for a mobile phone company. Let’s have a look back at the example I mentioned earlier;

“Monique has just started her first full-time job. She calls a mobile telco to set up a pay-monthly contract. After 20 minutes of sharing her most personal information, the call is dropped. When she calls back, she’s made to start again because their systems don’t allow her to pick up where she left off.”

Let’s imagine working on the ‘I want a new mobile phone contract’ journey. We’ve interviewed new customers to get their story and we’ve had a look at data such as call volumes. We’ve even managed to speak with some customers that dropped out of the process. We’ve identified from complaints and NPS verbatims that people being unable to complete dropped calls is a big deal. The volume of dropped calls is about 8%. And we’ve managed to drill down a little further to see that 50% of those 8% of calls actually never call back again. So, not only is this causing misery for those people signing up, the company is losing potential new customers.

The workflow process for new signups isn’t set up to handle new calls half-way through a process and the operators are usually very quickly re-assigned new calls to cut down on the call queue.

These kinds of issues are great places to intervene with solutions, because the business case writes itself-more signups = more revenue.

If you’re a good detective, you’re not prepared to accept the first alibi you come across. It’s not enough to accept ‘That’s just the way we’ve always done things”. So, at this point you might start to feel less like Steve Jobs and more like Columbo, the ferreting, genius detective from the 70s and 80s TV show of the same name. Because, the cause of this issue isn’t clear cut.

Let’s imagine that when the process was first conceived, 12 years ago, people mostly called on landlines. Landlines were popular back then. Over the years, the number of people experiencing dropped calls has steadily increased as more people are using mobiles on trains, fewer landlines, houses with poor mobile reception etc. In addition, you find that the number of seats for the telephone exchange software was limited to 2k and it tends to cut calls when it hits the limit. Budget hasn’t yet been allocated to increase the seats. Also, a few years ago, the organisation changed it’s insurer. The new insurer insisted that customers go through a more rigorous credit check, which takes an extra 4 minutes, on average. This massively increases the chances of calls being dropped.

Each of these changes to process have been patched on over the years until enough people complain that the organisation decides to spend some money on addressing it.

This kind of root-cause analysis isn’t always carried out in a service design process. But service design and user experience designers are well placed to not only diagnose these issues but also help stakeholders characterise the problem and conceive of new solutions. Some will dip into employee thoughts and feelings and make recommendations for training. But very often, employees are simply small parts of a systemic, habitual machine called an ‘organisation’. Their performance and behaviours are usually a byproduct of of the design of the machine itself.

Without understanding how the machine works, how can we make recommendations and plans for robust changes? How do we design for flexibility, interoperability, for change?

Systems pictures

A good way to understand what the machine is doing is to draw a picture of it. Most default organisational pictures tend to look like this;

I’m not sure why this is. Maybe it’s because human beings have a very powerful ability to classify things. We’re great at stereotyping people and situations and putting them in boxes. It’s easier for our brains. But what really matters to effective services isn’t which box they go into but how they interact, how they interoperate, how they supply each other, how they make demands of each other, their capacities, the nature of demand — how they work together. If we continue to look at organisations in this way, we’ll continue to have organisations who’s ‘bits’ aren’t working together to provide good services. Although the picture above is pretty crude, it’s how many organisations are structured — by function.

Here’s another, prettier version that shows Autodesk growing to 8k employees. Read more about that on Fascodesign.

Looks great right? But it’s saying exactly the same thing about the organisation as the stick people above. What both of these pictures show isn’t how the organisation works, they show how power works at the organisation — whom reports to whom.

I have no idea what Autodesk does. To guess I’d think they make desks. Maybe they’re standing desks that know when you’re standing and when you’re sitting? (they make software). Looking solely at those diagrams, you’d imagine that the sole purpose of both organisations is to protect the CEO, to defend them from incoming criticism, to act as the limbs of a tiny central brain.

Systems thinking can help

Systems Thinking is a way of creating a shared understanding of how something works by outlining the functions of it’s interdependent parts. That something could be a bath, a rainforest, Earth’s climate, city traffic or a business. The idea is that all things are interdependent. So if you change something, you never just change that one single thing. The change you make makes changes of its own. And it’s very difficult to work out what’s going to happen when you make a change. From a leadership angle, if you hire a great person to lead a sales team and sales go up, that’s great. But if you don’t have enough people to deliver on the sales, queues build up and you have unhappy customers and you begin to lose them.

Here’s a great intro from John Sterman’s course at MIT — Introduction to Systems Dynamics;

Systems dynamics and systems thinking often go hand-in-hand. Systems dynamics is more of a method of notation, while systems thinking is about ways of understanding through shared mental models. A systems thinking approach to service design will often work towards building a picture that expresses the underlying model of how the business works. If you’re looking at an overall customer journey for a specific task, then a systems picture would show how employees, databases, algorithms, management all interact to service the customer.

Systems thinking can help us in a few ways;

• People serving within the different functions of the organisation can gain a shared understanding of the organisation as a whole. See the Blind Men and the Elephant.
• We can create models of our assumptions that can be prototyped and adjusted to see how design decisions might pan out.
• We can agree on where might be best to intervene to create improved outcomes — getting the most of our limited resources for improvement.
• We can reveal hidden perspectives that few in the organisation have seen in one single place before.
• We can anticipate possible unintended consequences.
• We can understand the capacities of the organisation, which helps us to understand how efficiencies might be created.
• Understand trade-offs. There’s always trade-offs.

The diagram below is a systems picture which uses systems dynamics notation to communicate how the concept of the Earth’s population works;

This is what’s known in systems dynamics as a stock and flow diagram. The only stock here is the amount of human beings currently alive on the planet i.e. the population. The only factors that effect population is births and deaths. These are the flows, usually the things that replenish or deplete the stocks. The rate of births that occur is called the fertility rate, while the rate of deaths is the mortality rate. The little dashed line is a feedback loop. The one on the left is a reinforcing feedback loop. The one on the right is a balancing feedback loop . Feedback loops are generally observations and controls which effect the rate of flow into the stocks. Examples of (attempts at) balancing feedback loops relating population are China’s One Child policy or Nicolae Ceaușescu’s policy of criminalising abortions in Soviet Romania in the mid-1980s.

Introducing diagnostic service blueprints

As discussed, service blueprints generally don’t go deep enough into understanding how the organisation functions. In recent years I’ve been attempting various ways to bring together the classic techniques from systems thinking with service design. Very recently, I’ve started to use a combination of the service blueprint, described above with systems dynamics notation.

Above is a basic schematic of how a combination of systems dynamics can be used on a service blueprint. I’ve used this approach very recently with a client to great effect.

If you’re interested in learning more about how this method might work, please comment or get in touch on Twitter or email.

Here are a few great books for understanding Systems Thinking further;

• Thinking in Systems: A Primer by Donella Meadows — Really useful for understanding the basics. There’s a handy list of ways in which you can intervene to create better outcomes (which I’ve borrowed from heavily here).
• The Lean Machine by Dantar P. Oosterwal — A case study of how Systems Thinking methods rescued Harley-Davidson’s then failing product delivery process.
• The Fifth Discipline — A thesis on how organisations can achieve their purpose more effectively through a combination of organisational learning techniques such as systems thinking and shared mental models, among other things.
• The Goal — How the understanding and optimising of constraints can benefit organisations as a whole.
• Systemantics — Archetypes of systemic failure (quite funny).