There is no framework for empathy

Frameworks and automation exist for virtually every aspect of building a web app. From HTML5 Boilerplate to Heroku we’ve abstracted a lot of the repetitive parts of making things on the web. These frameworks allow us to focus on crafting delightful experiences.

Frameworks and automation exist for virtually every aspect of building a web app. From HTML5 Boilerplate to Heroku we’ve abstracted a lot of the repetitive parts of making things on the web. These frameworks allow us to focus on crafting delightful experiences.

As I’ve learned design, frameworks have helped me level up more quickly. There are software frameworks like jQuery, but I’ve been helped as much (if not more) by books that outline design infrastructures like Josh Clark’s Tapworthy, Luke Wroblewski’s Web Form Design, and Steve Krug’s Don’t Make Me Think. Eventually every designer runs up against the limitations of how far a framework can carry you. When you’ve re-coded half of the template, or found a use case that is different from anything in the book, you know you’ve reached the end of the framework—the exciting and wonderful place where you get to make something new.

Your own private intuition

Unlike reaching the end of a framework, it’s much harder to find the limits of your empathy. My worst design failures have come from thinking that my gut-level idea of how something should work was exactly the way everyone would want that thing to work. It is very easy to confuse intuition with empathy, which is why prototyping is so awesome. Even after prototyping it can be hard to overcome deeply held ideas of how something “should” work.

There is no way easy way to find empathy for users and to develop the listening and processing skills to turn user feedback into magical experiences. I’m sure there are folks out there whose “user ear” has “perfect pitch”, but for the rest of us, the only hope is a couple thousand hours of talking to folks and many iterations of trying to solve their problems.

Where to spend your 10,000 Hours

I’ve been trying to build up a little “empathy library” of ways that other people are working to get closer to the real problems of their users. What I love about all of these articles is that none prescribes a simple solution. Rather, they all describe open ended sets of questions to be asked and answered.

  • The Understand (day 1) and Validate (day 5) days of the Google Design Staff “design sprint” are both packed with ways to try to build empathy into the design process.

  • Teehan & Lax in The making of Medium.com describe making one-pagers in which they answered the following questions to help define the problem:

  • Who is this page for?
  • What problem does this page solve for the user?
  • How do we know they need it?
  • What is the primary action we want users to take on this page?
  • What might prompt a user to take this action?
  • How will we know that this page is doing what we want it to do?
  • Ryan Singer has a great post on diagramming flows that I’ve found to be incredibly helpful in reminding myself that “Customers don’t teleport onto this page, they make a series of decisions that bring them here.”

  • The whole world of Clay Christensen’s “Job’s to Be Done” theory is a deep well of mind melding with your customers. I’m a big fan of The Innovator’s Prescription as an applied version of The Innovator’s Dilemma. Horace Dediu had an awesome conversation with Clay awhile back, and there’s a great podcast series discussing the theory in application.

All of these sources have one thing in common—they remind you that there is no framework for shortcutting the demanding and time-consuming work of building empathy.

I would love to add to the list. Tweet your favorite empathy resources to @benzoh.