Nobody likes to feel like an ‘edge case’
11th October 2020
When designing business processes or services, it’s tempting to focus exclusively on the ‘happy path’. The ‘happy path’ is the route that a majority of customers will tread, and represents the most common path through the process. It assumes that nothing unusual happens, the customer does everything we expect of them and everything works exactly as we have planned it. In reality, with anything but the most trivial of processes, there are actually several ‘happy paths’. There might be different possible start points for a process, and subtly different ways that the work flows depending on certain characteristics of the customer (an airline might treat a ‘gold’ customer differently from a ‘bronze’ customer, for example).
Whilst it is absolutely crucial to focus on defining and designing these ‘happy paths’, the unfortunate truth is that the world isn’t anywhere near as orderly and predictable as we might like it to be. There will be situations which don’t fit the mould, and if we don’t build a process that is flexible enough to respond to them, we risk damaging our relationships with customers. Or we might make things so difficult for those who have to work with the process (the front-line workers who generally want to ‘do the right thing’ irrespective of what the process says) that the process falls into disuse and disrepute. Even worse, we might inadvertently make our service inaccessible to vulnerable groups, or end up unintentionally discriminating against entire groups of the population – something I’m certain we all want to avoid.
Understand and expect exceptions
Anything outside of the ‘happy path’ is generally referred to as an alternative path, or an exception. Sometimes the term ‘edge case’ is informally used to highlight the fact that it only occurs in extreme or unusual circumstances. It’s easy to spend so much time focussing on the normal course of events that we neglect the exceptions, but doing this can be extremely dangerous.
Let’s take a seemingly simple but deceptively difficult example. Let’s imagine that a financial services company provides an online service which requires the use of a long password. The company’s terms and conditions explicitly forbid writing down or storing the password, meaning that customers must use their memory, and the service can only be accessed online (not by phone or in branch). This seems entirely reasonable on the face of it – after all, we’re all used to remembering passwords, aren’t we?
Yet what about the 850,000 people in the UK who are living with dementia, some of whom suffer severe memory loss? Or other folks who have conditions which might affect their short or longer-term memory? In our noble efforts to define a slick, efficient process for the majority of people we can end up excluding and marginalising a minority. These minorities aren’t ‘edge cases’; they are real cases, real people who just happen to have different sets of needs to the majority. Shouldn’t we embrace their needs in our service design activities? In fact, if we made a better authentication process that didn’t rely on the user remembering a long password, wouldn’t we make the situation better for everyone?
Diversity and flexibility can lead to better design
When it comes to service and process design, people tend to build things that work for people like themselves. If you haven’t knowingly met an adult who can’t read, you probably don’t consider the challenges that might be present in accessing even the most basic of services. If you don’t have any blind friends, you probably don’t think much about the practical difficulties that they might face. Of course these are only two examples, but they highlight the importance of building diversity into the teams that design processes. With a wider collective set of experiences we are more likely to build a service that works for a wider set of people.
A common critique of this argument is to say that we can’t cater for every situation, and in some cases an organisation might not want to. Organisations do have the option of selecting which customers they choose to deal with: a retailer is perfectly entitled to accept payment by card but not cash, for example. In doing so they remove the need to have any cash handling processes. The significant point is that this is a deliberate decision not an unintended consequence. It’s a strategic choice, not a mistake, and strategic choices are to be encouraged as they consciously narrow the scope of our processes and services – providing, of course, that these decisions do not inadvertently affect a vulnerable stakeholder group.
It’s also tempting to think that there are so many possible exceptions it’s just impossible to design a process that will cater for all of them. In most situations this is true; however an antidote is to build flexibility into the process and to empower the frontline staff who are involved in executing it. Do you really want to design a rigid process that caters for every possible scenario, or do you want to trust staff to do the right thing if something unexpected and unpredictable happens? You could define a process which has a specific exception flow telling staff what to do if the Queen arrives unannounced, but surely it’s better to just trust them? In building in flexibility, we avoid baking in unempathetic rigidity with staff that are obliged to speak from a script and use phrases like ‘the computer says no’. Again, this will likely create a better experience for everyone.
In summary, ‘edge cases’ typically represent real people. If we build diversity into our definition and design activities, we can ensure our processes and services work for the widest possible set of people. Empowering those closest to the customer to do the right thing in truly unexpected circumstances is usually better than trying to rigidly define everything that might happen.
by Adrian Reed, Business Analysis Expert