Let’s talk about something uncomfortable. You know that beautiful user flow you mapped out? The one where everything works perfectly? That one that works great for most of your users most of the time.

The problem, of course, is the users it doesn’t work for. They’re stuck dealing with divorced parents sharing custody calendars, trying to access their accounts after their phone got stolen in Barcelona, or attempting to use your app while their internet cuts out every few minutes because they live in rural Montana.

Edge Cases Are Tough

These are all examples of edge cases.

An edge case is a rare or unexpected scenario that typically involves unusual user inputs, extreme data values, or uncommon usage patterns that weren’t anticipated during the primary design and testing phases. Sometimes the rarest of them will be called corner cases.

Not every deviation from the happy path is that unusual, though. Some things we think of as exceptions are surprisingly common.  Almost every one of your users will run into at least one of the following problems at some point, if they stick around long enough.

The Cases We Don’t Think About

When edge cases fall through the cracks in our designs, it’s often because they’re scenarios designers would rather not consider.

Name Changes

The Scenario

Someone gets married, divorced, or transitions. Simple, right? Just change the name field. Except now their old name is baked into URLs, email notifications still use the old name, and other users can’t find them because search works only with the original name.

While a name change might not be an everyday occurrence for any given individual, it happens to somebody somewhere every day, and it should be easy for that person to handle it on their own, without having to jump through hoops.

Design Better

• Make names editable and reflect those changes everywhere in the product – even in URLs.

• Plan for gradual rollouts where both names work, at least temporarily, by default. For example, if somebody’s email changes, have the old address forward to the new one, or if somebody needs to be found in a directory, have the old name redirect to the new.

• Don’t be too strict on name-validation fields. If somebody wants to present themselves as “Pat NewName (formerly OldName),” you should allow that. This approach also has the benefit of not annoying people who have spaces or punctuation in their names, which is very common in many parts of the world.

• Consider that some users need their old names completely scrubbed for safety reasons. This may mean allowing the user to override the previous suggestion to make both names searchable! Both use cases are perfectly valid, and giving the user control over how they are presented to the world is always a good choice.

Account Lockouts

The Scenario

An email account gets hacked. A phone falls in the toilet. An authentication app gets corrupted. Your user is now permanently locked out of their account with three years of work inside it, and your Contact support form requires them to be logged in to access it.

Design Better

Multiple Accounts

The Scenario

Your user has a work account and a personal account, or maybe they’re a freelancer with separate accounts for each client. Your product treats this situation like they’re trying to game the system instead of recognizing it as a completely normal use case.

Design Better

• Account switching should be trivial. Don’t make people log out and back in every single time they want to change. In some cases, you can let people sign in once and then create multiple subaccounts or just associate multiple accounts with the same login information. For example, if a user has a work account and a personal account on a social media site or a teleconferencing app, they shouldn’t have to manage everything separately.

• For bonus points, allow users to share global settings across all their accounts. Users shouldn’t have to upload their profile picture or set their preferences multiple times if they don’t want to. On the other hand, don’t require any shared settings. There are lots of great reasons to have different settings for work accounts and personal accounts. Very few people want to sign into their work Zoom and have all their coworkers see their character name and avatar from their weekly Dungeons and Dragons session.

Shared Accounts

The Scenario

While your beautiful user model probably focuses on individuals, real people share accounts. Couples share streaming services. Families share photo storage. Sometimes one partner goes on a work trip, so both people will be using a product or service at the same time from different locations. Not everybody is doing this to avoid paying you extra fees. Sometimes it just makes sense to have linked accounts.

Many family plans allow people to track their movies or music separately depending on who is using the device. That way they don’t end up getting recommendations to watch a Disney movie on date night or a horror flick when they’re watching with the kids. If your product is likely to be used on a shared device like a television or an iPad, give users profiles and let them decide who the user really is.

Design Better

• Acknowledge shared accounts exist.

• Build features for legitimate account sharing like separate profiles and child safety features.

• Make it clear when sharing might be problematic for security without being punitive.

• Make it possible for people to disentangle their profiles and make separate accounts for perfectly normal reasons like break ups or kids going off to college, so they don’t lose all their data.

The Cases We Don’t Want to Think About

Bad Actors

The Scenario

Someone’s angry ex is harassing them through your platform. Trolls are gaming your community features to abuse other users. Your reporting system requires users to relive their trauma by documenting everything in detail, and even when bad actors are kicked out, they just make a new account and are back in no time. This can happen anywhere, even your enterprise product meant only to be used by teams at work.

We want to believe that everyone using our products is going to be a good citizen and treat others with respect and empathy. Unfortunately, over 40 years of electronic communication through bulletin boards, instant-messaging systems, and social media (plus thousands of years of…you know…observing humanity) have proven this is very much not the case!

Scammers, grifters, and griefers will constantly test your systems for vulnerabilities and use your products in ways you might personally find horrifying. The truth is that we’ve been building digital, connected products for far too long for you to pretend not to know this is coming. If you don’t design to prevent harassment and intentionally harmful misuse, users will assume you simply don’t care about the people being hurt.

Design Better

• Test your trust and safety guidelines by actively considering the worst-case scenarios.

• Don’t forget to do research, or even better, codesign, with folks who have experienced this sort of harassment.

A Deceased User

The Scenario

Death is the ultimate edge case nobody wants to design for. Your user’s spouse dies, and suddenly they can’t access the shared photo account because it was tied to their partner’s email. Or worse — every time they open your app, they’re confronted with notifications asking:

Where’s Mike? Invite him to collaborate!

In some of the worst cases, users have been reminded of the deaths of loved ones by automatically created photo retrospectives or anniversary celebrations of posts on sites like Facebook.

In this case, you not only need to plan for the eventual deaths of your users but also the deaths of anybody who is in any way a part of your system. If your users have taken pictures of a loved one, a friend, or a pet, those individuals might not always be around. An unexpected reminder of somebody who has passed away can be deeply traumatic, and you absolutely do not want your users to experience it on your platform when they’re trying to enjoy themselves.

Design Better

• Build memorial or legacy modes for existing users that can persist in some way after they are gone, while still recognizing the fact that they are no longer alive.

• Let users designate trusted contacts to manage their digital legacies online.

• Do not autocreate “fun” retrospectives of images or posts that may include terrible memories, or, at least, let users easily opt out of them or designate certain pictures off limits.

The Technical Realities We Avoid

Unconsidered edge cases also happen when a use case feels too complex or messy from a technical perspective.

Collaboration

The Scenario

Three people try to edit the same document. Two of them have slow internet, and one of them is on mobile. Your real-time collaboration feature becomes a real-time disaster with changes getting lost and confusion mounting. Or, even worse, you simply don’t have any collaboration features built into your system, so people end up emailing around files with ever expanding titles like Presentation_final_v3.5.key.

Design Better

Data Exports

The Scenario

Your user wants to leave your platform. They’ve got three years of data they need to take with them. Your export feature generates a CSV that’s missing half their information and is completely unusable in other tools.

This one sometimes makes product managers roll their eyes a little. After all, who cares what happens if somebody is leaving the platform? They’re not your problem any longer if they’re not your user! It turns out that many governments care quite deeply! Not only is this good practice, but, in many jurisdictions, it’s also the law that people be able to take their data with them when they leave.

Besides, just because your product isn’t right for a specific person doesn’t mean you want them telling other people how awful it was to leave your platform. Make it easy for folks to say nice things about you, even when they’re leaving, and make it an easy decision to come back some day when their needs change.

Design Better

• Export should be a first-class feature, not an afterthought.

• Test your exports by importing them somewhere else.

• Consider formats that preserve relationships and metadata.

Slow Connections

The Scenario

Your users travel or live in areas with spotty internet. They work in buildings with terrible WiFi. Sometimes they take the subway. Your app becomes a beautiful, useless loading screen whenever the connection drops.

As somebody who spent several years riding BART into San Francisco and having 90% of the apps on my phone work sporadically, if at all, on my commute, I am begging you to do as much as possible to make things work, even without a perfect internet connection.

Design Better

• Offline-first design isn’t just for developing countries.

• Cache intelligently, and, whenever possible, provide some sort of off-line mode.

• Show clear indicators of sync status.

• Let users work locally and sync later.

Accessibility as an Afterthought

Accessibility, while much larger than an individual edge case, is a chronic problem for digital design. And it gets overlooked for similar reasons — it can feel difficult or uncomfortable to consider.

Your product works great if you can see perfectly, hear clearly, and use both hands to navigate with precision. For everyone else, it’s a frustrating barrier to getting things done. And that “everyone else” is not a small number!

Did you know that, according to the CDC, more than 1 in 4 adults in the United States have some type of disability? At some point in our lives, most of us will have to deal with failing eyesight, hearing, or mobility.

Obviously, there are a lot of great resources on how to design better for all of the different accessibility requirements. We can’t provide an exhaustive list of dos and don’ts in this article, but be sure to remember that accessibility isn’t a feature to add later. It’s a design constraint to embrace and plan for from day one. Learn how to build accessible products and test them with real assistive technologies and actual users!

Stop Designing for Perfect People    

There are no perfect users living perfect lives with perfect internet connections and perfect intentions. The sooner we design for the messy, complicated (sometimes heartbreaking) reality of how people actually live, the better our products will serve everyone.

Your “edge cases” aren’t always edge cases. They’re Tuesday afternoon for a good percentage of your users.

The next time you’re mapping out user flows or making decisions about new features, ask yourself: What happens when this goes wrong? What happens when life gets complicated? What happens when this feature encounters the chaos of real human existence?

Then design for that too.