What to do when bad service design is deliberate
Most bad services don't happen deliberately.
In our most pessimistic hour, it might feel like all of the mismatched processes, obtuse rules or confusing processes we have to wade through have been created to test us, but very rarely this is the case.
In the vast majority of cases where we encounter a service that doesn’t work, the teams behind it were at the very least *trying* to improve it (even if their efforts weren’t successful).
But just because something rarely happens doesn’t mean it doesn’t. Every now and again, I come across an organisation that is using the poor design of its service to deliberately limit, triage or manage the volume or type of users who are using their service. When the mirror is held up, it can be exceptionally difficult to discuss.
Using bad service design to manipulate user behavior is a practice we almost never admit to, and is rarely ever used as a design method to proactively make a service ‘worse’’. Instead, the belief that we can and should use bad service design to change user behaviour usually only appears as a reason why we shouldn’t make a service better. This usually takes the form of a fear that making our service more findable/accessible/understandable will mean that we will be overwhelmed by the volume of users accessing a service, or we will end up with the wrong type of users in the service.
How do we spot deliberately bad service design?
Deliberately badly designed services can be exceptionally hard to spot, but its design is something that we should all learn to recognise. Whilst if crops up differently in different services, there are some general patterns that it takes;
Limiting user volume
Take, for example, a government service that gives people benefits or permission to do something (something like free school meals or a working visa). These services have rules to using them that are supposed to limit the number and type of users using the service, but rather than rely on that alone to triage our users, with deliberate bad service design we make the service hard to find, understand or use.
Limiting the type of users
We might also use bad service design to subtly change the type of people who use our service. For example a regulator that vets the quality of an organisation against professional standards might use obtuse or technical language in their assessment service to ensure that this organisation ‘passes’ some sort of hidden test that proves the depth of knowledge in the field.
Boosting user volume
Deliberate bad service design happens slightly differently in commercial settings, but it still happens. Instead of using bad service design to deflect the number or type of users in our service, we tend to use it to entice or entrap more users into a service that isn’t suitable for them. This tends to mean services are vague and unspecific in their initial descriptions (especially regarding their terms and conditions of use) whilst being extremely findable and accessible.
Limiting customer support
Equally common in private sector services and public services is using bad service design to limit customer support costs. This usually comes in the form of ‘noreply@‘ email addresses, hidden or premium rate contact numbers or near impassable IVR triage.
Manipulating additional revenue
Last but not least, some organisations will use poor service design to manipulate additional revenue from its users. This can happen by not letting them leave the service (a pattern known as the ‘roach motel’ where it’s easy to get in and harder to get out), sneaking in add-ons, panicking users into spending more money (hello airline pre-booked seats) or other barely-legal practices that boost revenue. This is obviously less common in the public sector, but not unheard of, especially in services that make a significant amount of revenue through fines for ‘non-compliance’. I was once involved in a road toll system re-procurement where the entire contract value for the supplier of the road toll system was based on the number of fines for non-payment of the toll they could generate. It was unsurprisingly one of the worst-designed road toll payment services I’ve ever seen.
It can be hard to know where to draw the line when saying that bad service design has been used deliberately or by accident.
It’s usually best to assume that an organisation simply doesn’t know what the right thing is to do, or that it does know and is finding it hard to act on this for some reason. However, if you find yourself in a situation where it’s clear that an improvement is being resisted because it would make the service ‘too easy’ to use, this is usually a sign that bad service design is being used as a tool to manage or manipulate demand in some way
What impact does deliberate bad service design have?
I hope this is obvious, but it’s important to say here - just because your organisation is using bad service design deliberately, it may be doing it with the best of intentions.
Most organisations have a limited field of view, so they simply don't see the long-term cost, risk or outcome implications of this sort of behaviour; not noticing the increase in complaints, refund requests, processing time or enforcement. The problem is that using bad service design is often simply just displacing cost, risk or missed outcomes to somewhere else. Out of sight, out of mind, like a piece of rubbish thrown out of a car window, we just move the problem to somewhere else or some time in the future.
Like most challenges in service design, the key to solving this problem is about finding the right language to explain why using bad service design causes more problems than it solves, both for us and our users.
So here goes, from the top, here are the main problems we create by using bad service design to manage or manipulate demand:
We exclude people without the resources to overcome our barriers
Bad service design is a really ineffective tool to triage or limit our user volumes. Rather than making our service easy to find and understand, then triaging or limiting the use of your service using clear and transparent rules (that you can make more restrictive if you want) we rely on a kind of endurance test to qualify for our service. This is usually by making the service hard to find, the rules of using the service unclear, or using obtuse and impenetrable language.
This means we end up with users who have the most time, money, knowledge or energy to overcome these barriers to use the service, who may not necessarily be the people we’re after. This means we might not deliver the outcomes we’re aiming for(especially if our service is targeted at vulnerable groups) and significantly limit the number of users who can pass our endurance test. If your service is supposed to be supporting a specific user group who aren't defined by their exceptional wealth, time, patience or existing knowledge of your service, this is going to mean you’ll end up with a very biased demographic of users that will reduce your revenue, increase your support costs and mean you don't meet your objectives
It stops us from understanding if our rules are effective
Whilst it’s true that most services will have limited resources, they’ll also usually have rules on who can and can’t use the service. If those rules aren’t effective on their own at defining the users that get to use the service, that is something that needs to be addressed. However, we can't do that until we actually allow the full spectrum of users who need to use our service to use it. Rigging the numbers or demographics with bad service design gives us a false sense of security that demand for our service is lower than it really is. This makes it really hard for us to financially plan for the future when we don't really know what the demand for our service is, and as we saw above, means our most in-need users often fall between the cracks, potentially generating cost else-where in the ecosystem.
We increase the cost and risk of our services, and other people’s
Ending up with the wrong users in our service is expensive. It generates questions, complaints, refund requests and increases wait times for users who should be in the service. It also puts more pressure on enforcement services as we need to stop people from doing the wrong thing by not making it easy to do the right thing. We frequently see this cost turn up downstream to the problem we’ve created, where users who should be using the service aren’t, creating pressure on other services outside of our own.
How do we change services that have been deliberately badly designed?
If we’re in a situation where our organisation is using bad service design to manage or manipulate user behaviour, our first step is to point this out.
Part of our challenge is that this deliberate bad service design is more of a belief system akin to a superstition (that if we make all or part of our service easy to use ‘Bad Things’ will happen) rather than something we engage in consciously. Our organisation might not know its using bad service design to manage demand, instead it might identify with having a fear of the consequences of making the service better. Either way, always point this out sensitively and don't assume that malicious intent sits behind this.
Creating the conditions for service design to thrive involves creating a safe space for people to make mistakes, this is absolutely one of those times. You could use the Good Services Scale to do an assessment of your service as a group to highlight areas where there are obvious issues.
The fear that our service might lose revenue or be overwhelmed by demand if we make it better is a legitimate one. Pretending that this isn’t going to happen isn’t going to make anyone feel better. If we’ve been using bad service design as a crutch for a long time, it’s natural for our organisation to worry what will happen if we take it away, so it’s important to point out the negative impacts highlighted above could be far greater than the cost of making the service better.
In these sorts of situations it can be helpful to prototype what a better service would look like and test what happens to demand or behavior in a private beta, agreeing a gradual, phased approach to removing the barriers your users face and creating a plan to monitor the effect on demand.
Remember, what get’s measured get’s done
One of the issues we might be up against is that the way we measure our services can sometimes lead us to deliver worse services. For example, a university might measure the number of applications to each course as a marker of success, but because of this single measure of success becomes extremely reluctant to make the eligibility rules clearer, meaning that it spends increasing amounts of time sifting and rejecting applications that aren't suitable for the course.
When we only measure things other than the outcome we’re trying to get to (ie. we only measure ‘applications’ rather than ‘applications and successful awards’) we can very easily incentivise ourselves to provide a worse service. This is by far the most common reason why we might use bad service design to change user demand or behavior. To change our service we will need to change how we define and measure success.
That means measuring the outcome you want to see, not just the tasks you want to get done. Removing KPIs can be extremely difficult (especially ones we use for long-term or industry-wide benchmarking) so think about augmenting and adding to your measures instead. Just make sure you agree these with your stakeholders.
If you’re looking for help to create the space for service design in your organisation and are experiencing issues like this one, try our Service Design Leadership course or Agile Service Design course which delves into the detail of researching, designing and testing services.