In our drive for speed, we have conditioned ourselves to ignore our most vulnerable users. We design for the happy path, and society pays the price.
The happy path
To create digital products, designers often start by developing a set of scenarios or use cases. These scenarios help determine the features, interactions, and technological infrastructure required in a product.
As an example, let’s think about Facebook. When Mark Zuckerberg was initially creating the social network he may have had a scenario like this in his head:
“An undergrad who wants to share pictures from a party with her friends.”
This is a straightforward statement, but even something as simple as this can help a designer conceptualize the kind of solution required. In the case of a digital product, they can start to imagine the screens that might be needed, the elements on those screens, and so on.
Scenarios come in two basic flavors: happy path and edge cases.
The happy path is a scenario where everything is perfectly aligned for the feature/product to work exactly as the designer intended:
“A benign undergrad goes to a party and takes some inoffensive pictures. She comes home to her computer [remember this is early Facebook] with excellent internet connection, she logs in and uploads her photos with no issues, they go into the database and are disseminated to her friends.”
This is a happy path as we think of it today. As Goldilocks might say, everything is just right.
Many designers start with the happy path because it’s the path of least resistance. It takes the least amount of effort to conceptualize because it removes many of the inconvenient complexities that might exist. That doesn’t necessarily mean it’s easy to design; it’s just comparatively simplified.
The second type of scenario is the edge case. Edge cases deviate from the happy path and, theoretically, they happen less frequently than the happy path. There are two types of edge cases.
The first are technical edge cases, where something goes wrong in the technical flow of the scenario. Maybe there is an error in the photo upload process and it never goes through. Or maybe a user inputs incorrect data in a form field. This is the kind of technical complexity a QA person can test for. Very often a design process will address these kinds of edge cases, or will at least address the major ones. Any decent designer or engineer knows it is important to handle errors and help the user recover from them.
Then there are what I call contextual edge cases: behavioral deviations from the happy path. In our photo upload scenario, a contextual edge case might involve the user uploading a photo that is offensive or pornographic, or uploading a photo of someone else who doesn’t want that photo to live on the site. This kind of edge case can have very significant real-world implications. Unfortunately, these are also the edge cases that rarely get addressed in the design process.
The drive for speed
Today, success in the tech world is defined by speed, scale, and growth — how big can a company get and how fast can it get there. Facebook’s motto is “move fast and break things,” and product teams throughout the industry obsess over how quickly they can “ship features.” VCs even write books about how to run startups in hyperspeed, so you can validate (or invalidate) your idea as quickly as possible and waste the absolute minimum amount of people’s (read: VCs’) time. They call it “blitzscaling.”
The idea of moving quickly has become deeply ingrained in our culture of design, technology, and business.
One of the ways we achieve speed is by focusing on the happy path. Often a team’s strategy is to get the happy path done first as an MVP (minimum viable product) so they can quickly get it out to users before they put more effort into handling edge cases. The problem is that teams rarely come back to handle edge cases. Inevitably, new priorities come up and everyone moves on. What was once considered an MVP is now considered a final product.
Over time, this constant deprioritizing of edge cases conditions designers and engineers to just start ignoring them. Overloaded with work and impossible deadlines, it becomes easier to just pretend edge cases don’t exist.
The impact of the happy path
A few weeks back, a startup called Superhuman released a new “read receipt” feature for their email client product. If I send you an email using Superhuman and you open it in whatever email client you use (Gmail, Yahoo, etc.), the read receipt feature sends me a notification telling me you opened it. Straightforward enough. But there were two twists with Superhuman’s implementation. First, the read receipt didn’t just tell me that you opened the message, it also gave me location data of where you were when you opened it. Yikes. Second, you, the recipient, had no way of opting out of the feature. Regardless of the settings in your email client, you would always send me a read receipt. Double yikes.
This kind of feature has huge implications for victims of stalking, abuse, and so many other negative scenarios. Unsurprisingly, there was an outcry, and Superhuman modified the feature. But the feature should have never left the gate in the first place. When the controversy happened, Superhuman wrote a blog post and the CEO tweeted an apology:
3/ I am so very sorry for how our read status feature made folks feel. We did not imagine the potential for misuse. Now we are learning and changing.
— rahulvohra (@rahulvohra) July 3, 2019
“We did not imagine the potential for misuse.”
If this tweet is to be believed, it seems the idea that there could be deviations from the happy path didn’t even come up in the design process. It wasn’t even on their radar. Our drive for speed has conditioned us to design as if edge cases don’t exist. It’s not that we just decide not to solve them, it’s that we don’t even imagine them. These are practices handed down across companies and design schools. Many of us are so well trained at this point, slowing down doesn’t even guarantee a better outcome; ignoring edge cases is subconsciously baked into our process.
As companies push for scale and growth at breakneck pace they are weaponizing technology against groups that fall outside of their defined happy path.
We’re watching the cumulative impact of this play out on the web every day. Massive platforms like YouTube, Facebook, and Twitter were all architected with a best-case-scenario, happy-path mentality — a benign user sharing what they had for lunch or posting a video of their cat. The edge cases of abuse, harassment, and misinformation were all but ignored until they reached a scale where public scrutiny made it impossible to continue ignoring them, but by then it was too late. Addressing edge cases is not in the DNA of these companies. When you have spent 15 years fusing your business model to the happy path, your processes, organizational structures, and mentality are not geared to think beyond it. So these platforms are either slow to respond or completely incapable of it.
Happy path design is not human-centered, it is business-centered. It’s good for businesses because it allows them to move fast. But speed provides no benefit to the user. As companies push for scale and growth at breakneck pace they are systematically weaponizing technology against groups and use cases that fall outside of their defined happy path.
Who is in the happy path?
Part of the justification for happy path design is that edge cases are rare. In some cases, they might only affect 1% of a product’s users. Mike Monteiro points out the fallacy in this thinking in his book Ruined by Design:
Facebook claims to have two billion users…1% of two billion is twenty million. When you’re moving fast and breaking things 1% is well within the acceptable breaking point for rolling out new work. Yet it contains twenty million people. They have names. They have faces. Technology companies call these people edge cases, because they live at the margins. They are, by definition, the marginalized.
On top of this, the actual process of happy path design often involves having a default user persona who fits nicely into your complication-free use cases. This compounds the happy path problem because it means we are not only looking at a contrived view of the scenario itself but also at an artificially small slice of potential users.
After all, the happy path is free of risk and complication. By definition, the people with the least risk and complication are the least vulnerable users of a product.
Everyone else, as Monteiro pointed out, sit at the margins and are given almost no thought until after the damage is done and there is some kind of outcry.
More often than not, the humans who sit on the margins of our products are the same humans who sit on the margins of society.
When Superhuman was designing their read receipt feature, they weren’t designing it for people at risk of stalking and abuse (statistically, most likely women). They were designing it for their default user, who I would assume is some VC (statistically, most likely a man) sending off an urgent email to a founder (statistically, also most likely a man).
I’m making an assumption here — maybe they include women personas in their design process — but here is the real rub: Their personas are irrelevant. Despite what we say about having empathy in design, the default user is always ourselves. The idea of designer empathy is the biggest trick we’ve ever pulled on ourselves. Unless the person you are designing for shares your life experience, you cannot put yourself in their shoes in any meaningful way. Uncovering consumer insights is not the same as empathy, and human-centered design is not a magic shield against bias.
The humans who sit on the margins of our products are the same humans who sit on the margins of society.
A quick perusal of the Superhuman website shows that their product and engineering team is 83% dudes. Maybe someone pushed back on the read receipt feature, maybe they didn’t. But it’s almost guaranteed that a dude made the final decision. By and large, dudes don’t walk around afraid of abuse or stalking. It is, by and large, not our life experience.
“We did not imagine the potential for misuse.”
Designing for speed has trained us to ignore edge cases, and the overwhelming prevalence of homogenous teams made up of the least vulnerable among us (read: dudes) has conditioned us to center their life experience in our design process.
The canary in the coal mine
Miners used to take canaries with them into the coal mine. The idea was that the canaries were more vulnerable to the harmful gases that can build up in a mine. If the canary was fine, everyone knew things were safe. If something happened to the canary, it was a sign for everyone to get out.
This is a robust system. If you design for the well-being of the most vulnerable, you design for the well-being of everyone. We don’t design like that today. Today we design for the least vulnerable and then pretend nothing bad ever happens in a coal mine.
The breadth of the scenarios we consider determines how resilient our products are to deviations in the intended behavior. Today we are building massive platforms, with massive reach and impact, yet they are massively fragile. If we are honest with ourselves, these platforms represent a failure of design. Their success hinges on an intentional disregard for human complexity, and society pays the price for it.
The real happy path is not the path of least resistance; it’s the path of most resilience.
We have to redefine what a happy path is and relearn how to embrace complexity. In our Facebook photo-sharing example, what if our initial scenario looked something like this instead:
“A guy shares a compromising photo of a woman with his friends, and the woman is able to remove it from the site.”
This is what a happy path should be. It gets us to the same place as the original statement, and we still have to design and build the interactions required to let that guy share his photo. But it also does something crucial: It centers the most vulnerable user over the least vulnerable. It bakes the idea of misuse and negative outcomes into the core of our thought process and fuses it into the DNA of the organization.
—
The real happy path is not the path of least resistance; it’s the path of most resilience.
A lot of entrepreneurs talk about “first principles” as a way to identify their assumptions and guide their product development. While it may never have been explicitly stated, the inherent bias in our product development approach has meant that our underlying first principle has been to ignore human complexity. Redefining the happy path means establishing resiliency as our underlying first principle and moves the vulnerable to the center of our thinking. It forces us to embrace complexity and understand that when we design for the vulnerable, we design for everyone. No more half solutions.
Would this approach slow teams down? Maybe a bit, but we are not talking about creating “perfect solutions,” just slightly more robust ones that center someone other than your average white guy. I would also argue that if the success or failure of your company is determined by a few extra days/weeks of development time, there are bigger problems going on.
We will never be able to come up with scenarios for every possible edge case; it’s impossible and that’s not what I’m suggesting. We also don’t need to. By starting with even one, we fundamentally change the foundation of our thought process. This kind of structural shift can enable individuals and organizations to cultivate the competencies and capabilities required to not only flag potential future issues, but to bring real solutions to the table when they inevitably emerge. That’s a happier path for everyone.
—
“Edge Cases Are Real and They’re Hurting Your Users” was originally published in Medium on September 4, 2019.