Tragic Design

When is the last time you wondered if your work might have killed someone? This book wants to make sure no designer ever signs off on work without considering the consequences of their decisions.

There’s a concept used in the healthcare field called the Swiss Cheese model of accident causation. This model (see Figure 1-2) compares human systems to multiple slices of holed cheese. There may be multiple layers to pass through before a mistake affects the patient. For example, when there is a medication error, the source of the error can occur in any of these “layers”: the doctor’s prescription, the pharmacist filling it, the medication being stocked correctly, the nurse preparing and giving it, and the mechanism used to administer it to the patient. Each layer has its own holes (flaws in the preventative measures), but together they reduce the chances of an error happening. In our example, nurses were the last layer of defense, so it’s easy to blame them for the mistake that happened. But in fact, interface design should act as the last layer in that model. It usually accomplishes that by reducing the cognitive load required to complete a task, thus allowing more resources to be dedicated to error prevention. Unfortunately, in the healthcare industry, it instead leads to making more holes.

We would define design, especially in the sense of designing products and software people will use, as “the planning of a product’s interaction with people.”

We are often fooled into thinking that what we made was successful, when in reality the cost is hidden or externalized. Failing to identify all of the hidden costs and the impact of our designs on the world around us can lead us to blindly and unintentionally cause harm to others. In order to identify and avoid these potential hidden costs, we suggest creating lists of “goals,” “non-goals,” and “anti-goals” (also called “hazards”). They can be added to the product brief or creative brief, if your company uses these. While the concept of “goals” is pretty straightforward, the two latter sections are rarely found in product design briefs. The list of “non-goals” aims at setting objectives that are explicitly out of scope for the current effort. While this might sound unnecessary, in our experience there is value to being explicit about things that are out of scope, in case there is ambiguity about the boundaries around one or more goals, or any tendency toward “scope creep.” The third section, “anti-goals,” is used to describe things you really, really don’t want to happen. This section should be followed by descriptions of how you will make sure the anti-goals don’t happen, with precise test objectives. We call these “safeguards.”

Our job is to think about this when we design our products. Here are some good questions to get us most of the way there. They should be asked when designing any new or enhanced feature: How might people abuse this feature to hurt others? If this feature is being used for abuse, how can a user take action against it? Is the banning system top down or bottom up? If it’s top down, can it scale? What are the consequences of someone abusing others? What do they have to lose? If we add more safeguards, do they distract or discourage interaction from the rest of the users? If so, is there a way to do so without distraction? Are there any incentives for someone to abuse?

If when we ask ourselves “What’s the worst that could happen?” there is a chance that something might hurt or kill someone, then it should become a priority, even if the odds of this happening are really slim. The safeguards put in place can be annoying to some users. However, we argue that it’s perfectly acceptable to be annoying to most of your users, if it’s to avoid causing pain to a minority. Preventing harm to a user should always triumph over a feature. For example, when a visitor searches for “sad,” the blogging platform Tumblr will offer help instead of actually showing the search results (see Figure 4-8). Even though this might be useless to most people and forces an extra click, it could make a great difference for a few users. It is absolutely worth it. In addition, it shows other users the genuine care Tumblr has for them and the rest of the user base.

45-minute activity that can be done as a group. We call this the catastrophic brainstorm. The goal is to invite as many people as possible into a room and ask them, “What’s the worst that could happen with our new feature?” Each participant has to come up with a catastrophic scenario, write it on a Post-it, and stick it on the wall. Encourage all participants to be creative! We find that coming up with funny examples at the beginning helps to break the ice. Once you have a bunch of Post-its on the wall, vote for “the worst thing that could happen.” The top three scenarios should then be seriously considered as a priority on the roadmap.

One of the best investments of a designer’s time is to book a recurring one-hour meeting with one or more customer support representatives and shadow them as they take calls. They are a fountain of knowledge when it comes to the user experience issues that need to be resolved. Additionally, they generally know the product better than a lot of the designers. Listening to actual customer calls is one of the most eye-opening and humbling experiences a designer can have.

research shows that our brains can be analytical and empathetic, but not at the same time.[ 53] A team at Case Western Reserve University studied the way our brain physiology limits simultaneous use of both analytical and empathetic networks. Here’s an excerpt from the report:[ 54] How could a CEO be so blind to the public relations fiasco his cost-cutting decision has made? When the analytic network is engaged, our ability to appreciate the human cost of our action is repressed. At rest, our brains cycle between the social and analytical networks. But when presented with a task, healthy adults engage the appropriate neural pathway, the researchers found. The study shows for the first time that we have a built-in neural constraint on our ability to be both empathetic and analytic at the same time. Accordingly, if you want to engage your team on an emotional level and create empathy toward your users, it is important not to overwhelm them with hard data. We suggest creating two parts in your design findings presentation. Start with your quantitative findings: the number of customer service tickets, results from Likert scales, the time to completion of different tasks, the error count, the conversion numbers, a cost-benefit analysis, and analytics from Google or other platforms. Then, present the qualitative data: customer journeys, Plutchik’s wheel of emotions (that we will describe later), notes from observations during user tests, findings from interviews with customer service representatives, etc.

As a base, we suggest using Robert Plutchik’s emotion wheel:[ 56] its greatest benefit lies in its simplicity. There are a lot of different theories about emotions, but most of these agree that they manifest in different intensities and that the basic emotions can be combined with others to create new emotional states. For example, on Plutchik’s wheel, a mix of acceptance and apprehension creates submission.

There are many ways of creating customer journeys. We suggest the excellent canvas proposed by This Is Service Design Thinking

Adaptive Path, the user experience design and consulting firm, also has a wonderful and free guide that helps with mapping experiences (see Figure 6-5). Finally, for a complete overview of the different journeys, diagrams, and blueprints that exist out there, see Mapping Experiences, by James Kalbach (O’Reilly).

In his book Articulating Design Decisions (O’Reilly), Tom Greever gives great advice for designers. He explains the process of preparing for and presenting your designs.