Often after we finish designing a solution for our product and believe all the things are correct, and then one developer from our product team asks us:

Are you aware of how you handle the case where the user…?
There are times when we will say YES, and other times when we will say:
I didn’t think about this case and I have to resolve it.

One of the points that always complicates the product design work and takes longer to solve is when the designer realizes that there are some edge cases in the design (sometimes called corner cases) that need to be solved to be able to ship the product.

The purpose of this article is to describe how I find edge cases, how I deal with them, and why I prefer not to solve all of them.

First let’s understand the difference between happy path, different cases, and edge case

Let me start by explaining a bit about 3 different and common situations we encounter in our design process to better understand the article. Although there are places where it can be further divided, I found that these 3 explain the concept in the most straightforward manner. A login flow will be used to illustrate the point.

• Happy path
  A happy path (sometimes called a happy case or a happy flow) refers to a situation in which a user takes action and achieves their objective without any difficulty. This is the most common scenario and is the path that is taken by the majority of users. In the case of logging into an app, a happy path would be:
  The user enters the app > the user adds his/her email address > the user adds their password > the user clicks on the login button > the user logged in.
• Different cases
  I call it different cases in this article, but it is known as error cases among designers. Now imagine that the user wants to enter our system but cannot because they have forgotten their password, there is no straight line to reach the goal, and we need to help them with it. In most digital products, there is a “Forget Password” button that, upon clicking it, sends an email with instructions for changing the password. The majority of the time, there will be more than one flow to solve, and this will depend on the flow of a particular product. Cases like this are quite common, so we should resolve them.
• Edge case
  Let’s imagine our user forgot not only their password for our system but also their password to the email they registered with. This is an edge case, a moment when a user pushes our system to its limit. The example that I show here is an extreme case that may happen to a small number of users. This is why it is called an edge case.

Why we need to solve edge cases:

Solving edge cases is important from two perspectives. In the first place, from the perspective of the user, but also from the perspective of the code.

Edge cases that are not addressed can negatively impact the user experience. Let’s look at some examples below:

The user experience point of view
Suppose you are working on a product that allows users to upload files to a cloud for backup. A user can upload any file they want and give it a name up to 64 characters. 99.99% of the time, the user uses up to 50 characters. Imagine a user typing a name consisting of 150 characters. In that case, the user will not be able to see the whole name they gave to the file. This can affect the quality of the user experience.

The technical point of view
On the other hand, we also have to deal with edge cases because of technical issues. Let’s continue the cloud backup example. Let’s say our system is capable of uploading files up to 10 Gigabytes (each file can have up to 10 Gigabytes). 99.99% of the time, users upload files that are between 1MB and 500MB in size. Think about the edge case when someone uploads a file that weighs 2 terabytes. In this scenario, it’s important to be aware that our system is at risk of collapsing.
In the event you work with developers, they will typically notice technical edge cases and raise a flag and ask about them.

We saw above two examples of edge cases, one from a user's perspective and one from the technical viewpoint. Neither is more important than the other, and we must consider how to address them.

I would like to point out that we do not need to solve all edge cases, as sometimes it would not be worthwhile. Throughout this article, I address moments when we do not solve all the edge cases and explain why.

How to identify edge cases in your design

According to my experience, there are three main methods I use to handle edge cases:

• I find edge cases during the design work, so I document all the edge cases in a document and review and solve them once the happy path and the different cases are resolved.
• After I have completed the design, I create a prototype with a design tool like Figma and begin to play with it, stopping at each screen and asking simple questions such as…
  -What happens if the user tries to upload a large file?
  -What happens if the file name is too long?
  -What happens if the user loses the internet connection?
• Show your design to the developers, and ask them to point out any errors or edge cases they observe. If you work with QA testers, you know they have the best eye for finding edge cases. As they test the product to its limits, they have a lot of experience with it; if you ask them if they see any edge cases in the design, you will notice that they will find them very quickly.

A correct process for identifying and resolving edge cases.

Generally speaking, what I found is that designers give a lot of thought to the edge cases and try to solve them before solving the whole design, which is, in my opinion, a big mistake.

Why paying attention to edge cases or solving them from the very beginning is a mistake?

As is the case at various points in our lives, we must first solve the most important issues before moving on to solve other issues, the same is true of the design process. In the first instance, a designer must understand that they need to find a solution for the most important part, the happy path, and then solve the different cases and finally solve the edge cases.

The happy path is the core of the solution, and we must put all our strength and effort into solving it in the best possible way. Because the happy path is the scenario that most of our users will use, we have to start from this point. Until the happy path is solved, I prefer to avoid touching the different cases and, most certainly, the edge cases.

The process I will follow is as follows:
happy path > different cases > edge cases.

I will explain it linearly, be aware that it is not always linear, If I find some edge cases during the design of the happy path, also in the wireframe stage before all the visual design is added, I write them down on a document and back to solve them at the end. I am not trying to solve the edge cases right away after finding them.

As an example, consider the following:
Our company sells vacations. Our users can find the best hotel deals on our website.
The happy path will be:
The user enters the website > search for a great deal > find a deal > pay > get a confirmation email.

Different cases will be, after the reservation:

• The user wants to cancel the order.
• The user wants to change the dates.
• The user wants to add a new room to the reservation.
• The user wants to upgrade from only breakfast to all included.

These are situations that we must deal with in our process, and they are quite common so many of our users might encounter them. In order to solve all the different cases, we must first talk to the project manager and developers.
We must determine which cases we wish to solve and which cases we do not wish to solve.

As a product designer, I would love to solve all of them, but other factors need to be considered, such as the time required to develop the solution, the release date, and the importance of the case. Therefore, I suggest you take your time and review them with the whole team to avoid working on something that is not necessary.

We are now dealing with edge cases. We can start working on edge cases once we have agreed and solved all the above. Normally I discover many edge cases during the design process, I go back to the doc I wrote and solve them one by one.

As an example, our form has a text input to write a name and a surname. For example, let's say that names are no longer than 15 characters, and sometimes people have two names, so we said that the text input would be 31 characters (15 characters for each name and a space between them). The 31 characters were also calculated for the mail confirmation.

Think about a user who wants to make a reservation on our hotel platform, and he or she has four names with 180 characters in total. In this case, the text input field is very short, so the user will not be able to see the name, and also the confirmation mail may not function correctly.

Edge cases like this can happen, but the probability is very low. We can fix this by enlarging the input field on hover to show all names and reducing the font size in the confirmation email.

We must now ask, do we need to solve this edge case? If we do not resolve the problem, what will the consequences be? As with many things in life, it is influenced by a range of factors. Let’s examine a few.

Is it necessary to solve all edge cases?

It depends on the situation

Here are two situations, based on the edge case we saw above, text input for a name.

Situation 1
The company has existed for 15 years and has more than 100 million users worldwide using its app

If the edge case in this situation is not resolved, it can significantly impact a lot of people. On top of that, because the company has users from all over the globe, you might see a long name from some countries.

Situation 2
The company started six months ago and has 1000 users, all of them from the same country. However, if this edge case is not resolved, it may not affect any user. Aside from that, the company is very young, so it is probably more important to put more effort into designing solutions for different places within the app than to solve a small edge case that will not affect anyone.

After reviewing these two scenarios, I believe the product team will resolve this edge case only for scenario 1.
We can see here that the solution will depend on the product and the specific circumstance, let’s take a look at some questions we can ask before we make a decision:

• How many users do we have and how many of them can be affected?
• Is it so important to solve this edge case? Will it have a significant impact on the user experience if we do not resolve it?
• Perhaps there is a technical problem?
• How long will it take to design a solution before it is released?
• How long will it take to develop the solution before the release?
• Are we before or after the product-market fit?

It depends on the product

There are products whose high quality is one of their main values. Take, for example, a product that calculates a company’s budget. When different edge cases continue without a solution, these, in turn, can have a big impact on a company’s bottom line. In that case, the PM may ask the team to address every edge case found. In the past, I have worked on a product whose core value was zero bugs and zero edge cases. In addition to creating a good UX design, my team and I worked to find and resolve any small issue we encountered by following this core value.

Identify priorities with the team

Whenever you design something new, you will always have to solve multiple edge cases. Designers sometimes pay too much attention to tiny things on the UI design that aren’t so important. By involving other members of the team, we can gain a better understanding of the big picture.

Listing all edge cases and prioritizing them is the best way to go. I recommend that you prioritize the edge cases in conjunction with the product manager and the developers. This will give the team a clear picture of these cases and help the team understand what is most important.

How to develop your ability to find edge cases.

At one of the companies where I worked previously, the PM chose for one month not to develop any new features or improve existing ones, just fix bugs. Because of that, I didn’t have a lot of work to do so I helped the QA testers for one month.

At the end of this month, I noticed that I improved my knowledge of the product, and I was able to detect edge cases easily.

If you work with QA testers, I recommend that you ask them to demonstrate how they test the product. They have work methods that help to improve this skill.

In conclusion

Edge cases are part of our UX design work and as a UX designer, you need to identify and solve them. We can find edge cases in the logic of the product, on the interaction design of a component, and also on the user interface.

It is always best to tackle the most important issues first, before tackling edge cases. Moreover, Differentiate between edge cases that require resolution and those that can be ignored.

Thanks for reading the article, I hope it will help in your work as a product designer. Please feel free to share it with your friends or members of your team, and if you have any questions, please let me know.
If you enjoyed my article, I suggest you follow me and subscribe so you’ll receive an email whenever I post.