Book review: Smarter, Faster, Better by Charles Duhigg

It’s not a book about UX per se, but I think a lot of the ideas in Smarter, Faster, Better: The Secrets of Being Productive in Life and Business by Charles Duhigg can apply to UX. Some people have criticized the book for being all stories and not enough practical tips, but I think that’s actually part of the book’s main point, which I’ll elaborate on throughout this post.

About the book

Smarter, Faster, Better is Duhigg’s follow-up to his book The Power of Habit: Why We Do What We Do in Life and Business. Both books were New York Times bestsellers and have sparked a lot of conversations on productivity. The main idea behind The Power of Habit is that the key to long-term behavioral change involves changing your habits. So if you’ve got a bad habit you’re trying to break, you have to replace it with a good habit.

The setup

Smarter, Faster, Better has a subtler message. It’s about making sure the habits you build are the right ones to get the results you want. It’s easy for people to trick themselves into doing something that looks useful but isn’t. To use a personal example, I bought an Apple Watch a while back in part because of the health-related notifications. And checking off certain things made me feel good, but I can’t say it led to any real significant changes, so I ended up selling it.

The book is basically a series of stories that the author believes support his idea. Duhigg received some criticism for this, and indeed, this criticism is often applied to any social science book aimed at a popular audience. The criticism is that the book is all anecdotal and not enough hard data. While I think that’s a valid concern, I also think the emphasis on stories is part of this genre, so complaining about it is akin to complaining that a romance novel is overly focused on relationships.

I get that hard science can lend an air of legitimacy to an argument, but I don’t think general audiences are convinced by tables and charts. Not because they’re too stupid to comprehend (I don’t think that’s the case), but because that’s just not how the mind typically works. Time and time again, I’ve seen stories change a person’s mind.

If there are scientific conclusions to be had, it’s good to know what they are. But anytime you adapt academic information for a general audience, you’re going to lose something in translation.


My favorite story in the book is one concerning a low-performing school district. As is often the case with such districts, governments threw resources and experimental methods at the problem to improve results, to little avail. One initiative involved collecting more data about students, results, and the teaching process. Although teachers praised the data tracking system, few were actually using it, and more importantly, test scores (you can argue that test scores are a flawed metric, but that’s not what this is about) weren’t improving. So a new policy was instituted: teachers had to go into the data room once a week and note the results on paper in some form, such as making notes on index cards or creating charts on butcher paper.

Adding a bit of what Duhigg called “disfluency” to the process increased the teachers’ use and comprehension of the data. Teachers reported improved interaction with students in part because having to process the data showed them more about the students as individuals. Students who might have previously fallen through the cracks got the help they needed. And test scores improved, to boot.

How the book applies to UX

You may have already noticed some parallels between UX and the ideas expressed in the book. There’s a lot of talk about reducing friction in user interfaces, but a little friction can be a good thing. Friction, once overcome, can give a user a sense of accomplishment. To use yet another personal example, I have 1-Click turned off on my Amazon account. I’ve heard other people report doing the same thing, and for the same reason I do it: to make impulse buys more difficult. So sometimes friction is the right tool for the job.

This gets at what I think is the main thesis of the book: you can never fully automate or outsource thinking. Data can help as a tool, but you still have to do your own thinking to draw meaningful conclusions.

If you’ve ever worked in a large organization, you’ve probably seen popular business methods (Agile! Six Sigma! Who Moved My Cheese!) adopted without regard to how they actually fit with the organization’s processes and goals. And that’s why the organization doesn’t magically become world-class after adopting these new methods. On a more insidious level, management can point to these methods as a substitute for offering better training for employees’ actual job duties or paying people better.

This behavior is seen in the UX world all the time, especially in the visual design space. “People like Flat UI and cool animations!” Well, it depends on the product. Animations can enhance an interface or be distracting, depending on the context.

I can’t think of too many things that are always good or always bad in an interface. So it’s important to ask yourself, “Is this the right tool for this particular job?” Context is everything. The most important skills are the ones in your head.

Have you read either of Duhigg’s books? If so, what did you think? Does the UX connection make sense to you? Let me know in the comments!

Leave a Reply

Your email address will not be published. Required fields are marked *