I recently read the book called Design for Real Life, and I wanted to share some of the notes that I wrote down while reading the book.

• Advocates for designing for the most vulnerable, distracted, and stressed-out users. If you make things for people at their worst, they’ll work that much better when people are at their best.
• There are a lot of edge cases where our design fails. See Facebook’s Year In Review, Flickr auto-tags, and Medium’s inappropriate copy.
• Edge cases = Stress cases. Instead of thinking about these things as edge cases, we should think about them as stress cases. These are scenarios where our design and content fail, and they should be treated like a failing unit test or integration test.
• Make a list of potential user scenarios. Here’s an example from the book:
  • People who want to share
    • Had a great year
    • Had a horrible year
  • People who don’t want to share
    • But want to relive it
    • Great year
      • Horrible year
    • And don’t want to relive it
      • Great year
      • Horrible year
• Find fractures in your design by challenging assumptions and finding stress cases.
• Make space in your design and accept a broader range of answers to accommodate your users:
  • Names: “Juan Antonio Gabriel Ancajas Talon,” for example, doesn’t fit in most input fields. Also, what is a real name?
  • Gender: Consider how a binary input field would leave people out.
  • Race: Consider how a generic “Multiracial” field would make people feel.
• Design to include: What if your period tracking app doesn’t support people outside of: “avoiding pregnancy,” “trying to conceive,” or “fertility treatments”?
• Classic edge-case thinking: “We’re designing for the 90%, not the 10%” or “That’s a difficult use case that I don’t want to think about.”
• “For now” can lead to “forever” for a busy team.
• Everyday stress cases (this can be people in crisis or something mundane going wrong). Examples from the book:
  • A person who as received a threat from a previously unknown stalker, and needs to delete or make private every public account as quickly as possible.
  • A university student whose roommate has declared they intend to commit suicide, and needs information on what to do.
  • Someone who has discovered their mortgage’s auto-pay has failed two months in a row, and is afraid they’ll be foreclosed on.
  • A person working two jobs whose only car was damaged in an accident, and is trying to submit incident information to their insurance company late at night, after they’ve finally gotten off work.
• Stress cases are also technical failures:
  • Low battery
  • Slow Internet
• Create personas that are real: Instead of thinking about ideal people who are smiling and have ideal lives, think about people who are distracted, short on time, have bills to pay, has dinner to prepare, and have kids to take care of.
• Just like mobile-first design, try stress-first design.
• Add contexts in your user journey. Consider who goes to the hospital in the morning, late afternoon, and at midnight. You’d find out that people who visit the hospital at midnight are people who are in crisis because normal visiting hours are over.

• Add intention to designs: Do you really need to ask income level, real name, mailing address, salutation, or level of education? Consider how people would feel: “Why do they need my postcode? Why do they need my gender?”
• Touchy subjects: Things that are likely to cause stress or make the reader uncomfortable (not just money, religion, or politics):
  • Error messages
  • Warnings
  • System alerts
  • Financial and privacy-related updates
  • Legal agreements
• 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 towards them but doing something with that empathy. Compassion is not meant to soften bad news or coddling. It’s understanding and kindness.
• The premortem: Evaluate the project before it happens to check our biases.
• The question protocol: Ensure that every piece of information you ask is intentional and appropriate by asking:
  • Who within the organization uses the answer
  • What they use them for
  • Whether an answer is required or optional
  • If an answer is required, what happens if a user enters any old thing just to get them through the form
• The designated dissenter: Assign someone in the project to assess every decision underlying the project, and asking how changes in context or assumptions might subvert those decisions.