The inherent exclusion of edge cases

Photo by YIFEI CHEN on Unsplash

Anyone familiar with the development of a digital product will likely have heard the term ‘edge case’. It is often used to determine whether or not a specific bug, feature, or other issue will have a big enough impact that would result in a larger negative effect than the team or business are willing to risk.

This often happens when deadlines are tight and minor bugs are found, or something big has flown under the radar and rears its ugly head late in the game and will result in the team pulling together and doing more work in order to address it.

In the latter scenario, the team will come together to discuss how much of an impact they think the issue will have on the product. In order to measure this, we think in a way which allows us to grade the impact; quite simply we use numbers. Admittedly hypothetical numbers in most cases, especially before a product or feature is launched, but it is the only way in which we can make our best guess in order to inform the business so that they are able to make the best decision possible, with a basis in some form of data.

This conversation within a team is usually held in the context of how much more time we can buy ourselves in order to fix the problem before it is released into the world. This tends to be because the issue will have such an impact that it is immediately assumed that it will affect the vast majority of its users should it be released without a fix of some kind.

Difficult conversations will be held with senior stakeholders, explanations as to why we are where we are at this stage, and a decision will be made about how to proceed and in what timeframe.

Because of the scale of the impact that such an issue would have, the decision will generally go in favour of doing everything you can to fix it in the shortest time possible, and we can still release without falling too far behind schedule, even if not everything is in the best possible shape. The result of this in the eyes of the business is that the vast majority of users will be able to use the product effectively at the cost of having to wait a little longer (unless a small miracle occurs involving a lot of overtime) for it to be available to them.

These big issues in delivering a digital product to market can raise problems in terms of edge cases, but the timeframes are usually so tight, we are unable to ascertain what edge cases there may be in such a scenario, and they tend to go unnoticed until they create a problem following release. This is part of an acceptable risk for the business, and there are bigger things on their plate in a situation like this.

This does not provide an excuse for any unconsidered edge cases, it simply provides the reason that they can come in to existence. In an ideal world, requirements don’t change, and big things like this wouldn’t be missed, but design and development is an imperfect process, and these situations will sometimes occur.

Then, there are the smaller things.

These are the slight changes that may take more work than is deemed necessary for what is seen as a minor benefit. A change that will affect a relatively tiny number of people who will use the product.

It is these smaller things where edge cases become a longer topic of conversation during design and development phases, and usually result in more work for both design and development if any of the smaller issues are overlooked.

What I am referring to as the ‘smaller issues’ here is actually perpetuating part of the problem. Seeing these issues as smaller assigns a connotation that they are somewhat less significant than the bigger issues, such as how a feature will function. These issues are thought of as smaller as they may not affect as many users, and therefore will have less impact on the bottom line of the product. The problem is, these smaller issues are often fundamental to building an accessible digital product. More often than not, these smaller issues will be made up of problems with accessibility, reliance on a single point of failure, non-semantic code and inefficient implementation.

It is too easy for us as part of a team leave the smaller things to each other, without specifically communicating what should be done. Leaving someone else to keep an eye on accessibility, or just assuming that it will be taken care of, is a lapse in judgement and fundamentally lazy. What’s worse is that we can use the same method of evaluating impact as we do for the larger problems, and because of the fact that these issues are intrinsically ‘smaller’ in size, and will have less of an impact, they are more easily swept under the rug. They are considered an edge case. A problem so insignificant that it will only occur for a relatively tiny number of the users.

You might be beginning to understand that I am not a happy bunny when situations like this occur, and here’s why. I am a great believer in the words of Sir Tim Berners-Lee; “This is for everyone”. The internet, and the World Wide Web that sits upon it, is there to benefit everyone.

Every time I enter into a conversation about an edge case, I am internally weighing up my ethical stance trying to ensure that we do our utmost to avoid discriminating against our users and the thing we make is usable by everyone, against the needs and stance of the business.

The most challenging conversations I’ve had around this involve accessibility (hence my previous mention of this specific aspect), and the amount of ‘additional’ work that is required to benefit a small percentage pop the user base. And it is in this middle ground where I become frustrated.

To arrive at such a situation must mean that we have already been ignoring our duty to build something that is for everyone. We have not raised the questions early enough in the process around accessibility and performance.

Correctly implementing the fundamentals of HTML make what you build completely accessible. Over time, we have layered on JavaScript, CSS, and now a multitude of front-end frameworks which increase page weight, decrease performance and introduce dependencies that the technology that some of our users may not be able to fulfil.

This is not going to turn into a rant about how evil JavaScript is — sorry to disappoint — but it is going to be about where we should be focussing our efforts when we are deciding on how we go about building our products to be used by real people.

When we are in a meeting room, and something along the lines of “it will only affect 1% of our users” is said, it can be taken as something that is too small to be worried about spending the disproportionate amount of time to fix. But what if you a user base of 5 million people? That’s 50,000 people who will have a negative experience — or worse, have no experience at all — when using the product.

As you may have guessed from the running theme in this article, I’m not a fan of using numbers to outline the problems, despite the fact that this kind of argument will carry more weight with senior stakeholders in a business.

I prefer to think fo the person at the other end. The individual who is trying to get something done using your product, only to find that you didn’t place enough consideration on their needs and how they would be negatively impacted by that experience.

If you feel that you are sufficiently distanced to think that this is not your problem when you’re part of the team delivering such a product, I want you to conduct an exercise.

Imagine that you are the product. Everything that the product will do, you can do. Now, think of your user who will not be able to use your product because of an edge case. They are standing in front of you, asking you to do the thing that you just did for hundreds of people before them, and your answer is “No”. How does that make them feel? How does that make you feel?

The internet is a tool for communication, but by not considering everyone as our users, we are immediately discriminating against those who may actually need what we are building the most. The World Wide Web exists to bring people closer together, closer to knowledge, closer to the things they need. It is our job as designers, developers, product owners, researchers, and anyone else involved in the process to prevent it from becoming a wall between people and their needs, from something that we can hide behind and dehumanise the work that we do.

Always think of the individual having the experience with your product.

How would they be impacted if this didn’t work for them?

How would they feel?

How would you feel if you were responsible?

Originally published at on July 21, 2020.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store