The Design of Everyday  Things

Human centered design attempts to delay defining a problem as long as possible. Rather, we should focus on increasingly accurate approximations of the problem.

The HCD approach discussed in this book focuses primarily on the research and design process. But if we extend and expand upon this thinking, we arrive at the Build-Measure-Learn model presented in The Lean Startup.

When software works as expected, users credit their own intelligence.

However, when software fails, users tend to blame themselves. We formulate stories in our own head to explain the failure as our own.

For product designers, this creates a precarious position. Not only do users blame themselves for what are likely design failures, but humans are also reluctant to share their failures.

In software, this roughly translates to the idea that when a user reports a bug, at least 10 other users are also experiencing that bug but haven’t reached out. As a software engineer, you can’t take bug report counts on their face. You often need to look into the actual bug to understand scale.

When I bought my house, I looked at the kitchen and liked it. Big countertops, a big sink, and beautiful tile work. Very nice features.

Here’s what I didn’t do. I didn’t stand in the kitchen pretending to cook an actual meal. I probably should have because I would have realized that I much prefer kitchens where I can stand at the countertop and turn around to immediately find the sink. This layout helps me prep and clean quickly and smoothly.

I still make due with my beautiful kitchen, but I wish the usability was better.

Software designers and engineers take pride in the usability of our systems and like to think that’s why users buy our product. Our software is good at solving problems. More likely they buy our products based on the features but stick around for the solutions.