Design for Real Life

Yesterday afternoon, on a rainy spring day here in Portland, I got under a blanket and read through Design for Real Life by Eric Meyer and Sara Wachter-Boetcher. This is an important book, especially if you have never thought through how the design of the thing you are making can translate into many different situations and scenarios.

A few years ago, when I was working on a product and helped out with support, I found out how easy it is to slip into the thinking that everyone is like me. But, in doing support, I was snapped out of that thinking, realizing very quickly that most people didn’t use the product the way I did. In many ways, Design for Real Life is a manual on how to jolt your self into the realization that many people use products in many different ways and situations.

Eric and Sara lay out the ways in which you can think through these things as you design and write and develop a new feature or product. They also show how different companies have successfully done this, maybe they made some big mistakes, but they also learned from them and worked to do better.

If you’re involved in the web, no matter your role, reading this book is worth your time; it’ll help you think about these things as your team works. Even though I’m often involved in the code of a site, when I’m in meetings about creating new features or sites, it’s important for me to think about these things as well. The more people who are actively thinking about this as your team works together, the better.

My highlights from the epub, broken up by chapter, are below.

Introduction

But making digital products friendly isn’t enough to make them feel human.

That’s why we’ve chosen to look at these not as edge cases, but as stress cases: the moments that put our design and content choices to the test of real life.

When we, the people who make digital products, don’t take stress cases into account, we miss out on designing for people who aren’t like us, people whose fears and challenges are different from our own.

Chapter 1

Engineers don’t have this skill naturally; they’ve been trained to consider worst-case scenarios. The same holds true for programmers. Most start out trying to write programs that will do cool stuff. Over time, they either see enough crashes and security exploits that they learn how to be careful, or they formally study computer engineering and are taught to be careful. Or both.

It’s the ability to simultaneously work toward and challenge your vision—to ask yourself not only, How can I make this even better? but also, How can I keep this from inflicting pain?

Moreover, whenever you tell yourself nobody would ever act a certain way or come to your site in certain situations, that moment should raise a huge red flag in your head.

Chapter 2

Designing for real people is also about making space: ensuring our interfaces and expectations don’t force users into narrow categories, prevent them from using a product in the way that best fits their lives, or make it difficult to complete tasks on their own terms.

To make design and content decisions that include the most people, we need to train ourselves and adjust our processes to invoke System 2 thinking as often as possible: to slow down, step away from our shortcuts, and consider things with real people in mind.

It might not be easy to convince your company to stop asking for unnecessary information, but as interface makers, we have a responsibility: to question the decisions and desires that cause harm to our users.

Lyle Mullican argues that we can apply Postel’s law to user experience design. Humans and machines parse information in fundamentally different ways, he writes. But machines can, and should, be robust enough to accept human information, make sense of it, and make it conform to their more programmatic standards….

…[W]e should be conservative in what we ask of them, only requesting the fields we actually need. But we should be liberal in what we accept from our users, rather than forcing them into our predefined categories.

…[F]or each person, only one use case matters: theirs.

Chapter 3

The personas we create often don’t leave the door open for these imperfections—and so we never imagine them in crisis scenarios.

Chapter 4

What’s missing is intention: making a specific, purposeful choice about what we’re requesting and why. That lack of intention creates real damage for our users, because every bit of personal information we request….

…[B]y being intentional about what we ask of our users in the first place, and communicating the context for every interaction as clearly and transparently as possible, we’ll greatly limit the ways we can harm or traumatize them, and also make it easier for them to forgive us when we do.

Chapter 5

Compassion is more than being nice. It’s accepting people as they come—in all their pain, with all their challenges—and not just feeling empathy toward them, but doing something with that empathy. It’s recognizing that users facing stress and crisis need more than our sympathy. They need our help.

But rather than simply helping designers get into the user’s shoes, like a persona might do, these principles go further. They empower the design team to do something to help, even when it limits PatientsLikeMe’s own options.

It takes confidence in what you are, and what you do, to set aside your ego long enough to help your users succeed. It’s a confidence many organizations don’t have.

When it did, it realized that funny mattered a lot less than helpful. It was time to change the way it communicated.

The point of compassion isn’t to soften bad news or stressful situations with niceties. It’s to come from a place of kindness and understanding, rather than a place of judgment.

Chapter 6

Critically, you want your interview questions to lead to what Portigal calls the tipping point: the moment when the conversation changes from question-answer, question-answer to question-story, where the participant uses your question as a launching point.

While asking people to describe the nonexistent product of their dreams won’t work, you can ask people to tell you about their vision for the future.

That’s why “tell me more about that” is such a magical phrase. It doesn’t lead the interviewee in a specific direction, other than toward more depth, which leaves a door open for them to go wherever they’d like with their answer. It also shows that you’ve been listening, because you’re looping back to something they said earlier.

What does make sense is to get beyond what your team first perceives as “ideal” or “average.”

Chapter 7

In many cases, the easiest way to stress-test any design decision is to ask, “WWAHD?”—“What would a human do?” When you’re designing a form, try reading every question out loud to an imagined stranger, listening to how it sounds and imagining the questions they might have in response.

We call this the “Designated Dissenter”—assigning one person on every team the job of assessing every decision underlying the project, and asking how changes in context or assumptions might subvert those decisions. This becomes their primary role for the lifetime of the project. It is their duty to disagree, to point out unconsidered assumptions and possible failure states.

Chapter 8

That doesn’t mean business cases aren’t worth making, though. Sometimes, you’ll be surprised at the potential financial impact you uncover. Other times, you’ll find that telling the story of kindness in budgets and bottom lines simply makes the conversation go more smoothly.

If you’re in an organization where customer service or support costs are high, you might use GDS as an example of how user-centric, empathetic design can have a real—and even impressive—impact on the bottom line.

Most of us don’t have the power to change our company’s values or realign budgets overnight. We do have the opportunity to become advocates for the users who are easiest to ignore: those whose lives and identities don’t fit the unrealistic ideals our organizations tend to focus on. The more we help others see the world from those users’ eyes, the more difficult it will be for them to push those users to the edges of our work.