A Counterintuitive Thought: Start with the 20% not the 80%
As business analysts, we work on services, processes and IT systems that are used by (or relied on) by some kind of ‘end customer’.
If our organization targets its services at the general public, then our ‘customer-base’ might be very wide indeed, with a whole range of different people interacting with the organization with all sorts of different goals. If you are working within a governmental environment, you may find you have almost unlimited variation—government departments rarely get to choose their ‘customers’ (a tax department can’t easily ‘choose’ who to deal with and who not to), and the processes are often enabled or constrained by ever-changing policies and laws.
When looking to automate or improve a process, often the focus (quite understandably) is on volume. “Let’s look at the happy path first, and then worry about all of the ‘edge cases’”. This is a totally understandable approach, and in some instances will be the best approach, but in doing so this hides the stark reality that it is often the edge cases that create a disproportionate chunk of the work.
We have probably all heard of the Pareto Principle, or the 80/20 rule, which is often interpreted to mean that in most business situations 80% of the work comes from 20% of the cases (and 20% of the work comes from 80% of the cases). This is actually a rather simplistic view of Pareto—it turns out that the 80/20 percentages were based on land ownership in Italy in the early 20th century, so it seems ironic we still use these approximations today, but that is a topic for another time. However, the underlying principle that the majority of work comes from the minority of cases would suggest that there would be benefits in understanding, and building for, the ‘edge cases’ early. Of course, to be more robust, we’d have to crunch the numbers and do a full and proper Pareto analysis.
An unexpected reality: Inclusive design benefits everyone
One thing I have been personally discovering as a practitioner is that inclusive specification and design actually benefits everyone. Designing well for so-called ‘edge cases’ probably means that you specify and design a process or service that is more intuitive and easier for everyone. It often means that your process is built to cater for more variety—so it can adapt when something unexpected happens. Of course, we need to design with the ‘plain vanilla’, the ‘exotic’ and the ‘edge cases’ in mind.
Let’s take one example. Imagine a bank develops a process where someone with Dementia, who can’t remember long passwords, can still use an online service (perhaps through some kind of biometric authentication). As their condition worsens, the service can be adapted to show less information, and eventually to prompt other family members if there are strange transactions being made. This feature might be designed with one specific need in mind—but I’ll bet a whole bunch of other customers would use biometric authentication, and others may well want family members to receive notices of any unusual transactions (for example, folks who regularly go away on business trips might want their partner or spouse to see any unusual transactions so that they can resolve them).
This is just one theoretical example, but I am sure there are many relevant examples in your (and my) organizations. As BAs we should question the assertion that we should always ‘go for volume’ and think of the happy path first. There is a danger that by considering the ‘happy path’ we end up carrying forward certain design assumptions—after all ‘edge cases’ are only ‘edge cases’ because our current processes, IT systems and so forth treat them that way! By considering these types of needs up front, we might be able to fundamentally re-design the service to be more inclusive for all, creating better outcomes all round.