December 1, 2020

Dead ends

Arguably, my experience with Screwfix the other day was due to breaking this 10th principle of service design: “A Good Service should have no dead ends.”

When the local store had to close unexpectedly and temporarily, whoever was responsible for closing didn’t have authority to update the main company website.   They had reached a dead-end in the process for closing a store, which in turn led to a dead-end for me, the customer.

When you’re designing a service or process it’s a good idea to start with the most straightforward and most frequently occuring case.  But as soon as have this, you need to consider likely exceptions, and include them in your documentation.  One important exception many forget, is that your product or service is simply ‘not for’ the person trying to use it.  This is a legitimate ‘dead end’ in a way, but helping them to make an orderly and elegant exit will do no harm to your reputation.

Often, dead-ends occur when you haven’t fully considered who your users might be.   Not every shopper is 100% fit and able-bodied.  Heavy doors and steps become dead-ends for the disabled, frail or heavy-laden.  Small print makes a web-page a dead-end for someone short-sighted.  Small buttons or too-precise hand-movements create dead-ends for the arthritic or shaky-handed.  As my husband found out recently, 2-factor authentication makes online banking a dead-end for those who don’t have a mobile phone.

Of course, you’ll never be able to predict every possible exception or variation, so you need to make sure your service or process always has an ‘escape route’.  A good start is to enable a user (whether customer or team member) to talk to a human being with sufficient experience and authority to handle anything.

If you find this backstop is called on regularly or too often, you’ve discovered another common exception you didn’t allow for.

As long as you learn from the times the backstop is called for, your organisation will quickly learn to minimise the need for it.