Imagine your product team is in the planning stages of building a new feature for your mobile application. You brainstorm all potential use cases, starting with your general use case. That is, the problem you built your app to solve and the type of person you know experiences that problem.
Then there are your edge cases. Edge cases occur when people use your app in a different way than anticipated or for a different reason or utility than you designed it for.
Let’s say you’re building an email app. You expect users to use two to four, or even 20 folders to organize their email. In my experience at Outlook, I learned some people have up to 3,000 folders. No joke!
In our situation, the general use case was someone with one or two email addresses and two to five folders for each. An edge case was someone with several email addresses or 150 folders, for example.
It’s up to you and your product team to decide if you want to design and develop your app to accommodate your edge cases. At Outlook, we didn’t have much of a choice.
Edge cases can create a conundrum. You want to keep your focus on users who provide the most value, but you also don’t want edge cases breaking your app. Below are the top considerations when deciding whether or not to design for your edge cases, based on my experiences.
When to design for edge cases
Yes, it’s important to focus on your core users. Everyone loves the famous 80/20 rule: focus on the 80% of your users who use your app the most or provide the most value (often monetary) rather than the 20% who don’t. However, there are some instances where you’ll have to design for your edge cases to maintain functionality for all users, including the ‘power users’.
Here are a handful of instances in which I found it was best to design for mobile app edge cases.
Scenario one: You have no choice
In the case of Outlook, we realized we had loyal customers wanting to use our app with 1,000 or more folders. This was how they functioned and it wasn’t going to change. The solution we found was to make a highly functional search tool. There was no way to design an app to list that many folders, but we could train users to search for a particular email or reminder. We had to design the search function to be readily available and easy to use.
Scenario two: Your app is available in multiple countries, across several languages
An edge case can be developed for people who speak different languages or are members of different cultures. Design nuances are important in these cases. Often times, a long name or name with characters will break a form design. Make sure all forms in your app can handle long or unique names based on the nationalities and cultures using your app.
Scenario three: You want to be accessible to everyone
I believe accessibility should be your number one consideration when designing an app. Did you know that 19.9 million people (8.2% of the US population) have difficulty lifting or grasping items (source)? This could impact their use of a mouse or keyboard, for example. Additionally, consider people with visual or hearing impairments. Make sure you have a diverse group of people testing your app before shipping it.
Scenario four: Different users have different technology
This scenario is most relevant to those running on a global scale. Some locations have access to higher internet speeds than others. Test your app to ensure it loads properly with the lowest speed possible. Also, consider what features, if any, should be downloadable or available offline. For example, consider who’s using your app while commuting or at home vs. an internet cafe. Similarly, test on all devices, including the really bad ones.
Building the bridge between mobile designers and engineers
You’ll never anticipate every edge case when designing an app. It’s more likely for an engineer to come across an edge case, but they may not have the best design in mind. Realistically, most product teams test for their general case and maybe one or two edge cases and hope for the best. When something breaks or they come across an edge case in the wild, they quickly scramble to fix and test it and it slows everything else down. This type of QA is expensive.
With Waldo, you can implement a new feature while QA testing it simultaneously. No more crossing your fingers and holding your breath that everything passes your tests and runs seamlessly. Our tool allows you to see what breaks before you’re done building a feature.
You won’t have to play guessing games to try to think of the most extreme edge cases. Because let’s be real, some users will try just about anything to see if they can break your app. Waldo will help you be prepared for anything without spending a fortune.
