Book Review — BADASS: Making Users Awesome

Book Review — BADASS: Making Users Awesome

The frustrating thing, I guess, is that all of us who make software want to make great software. Maybe there are exceptions to that deep down in the guts of some development shop in a government bureaucracy or the kind of ¬†Enterprise Development with¬†Capital Letters shop that gives that world a bad name, I don’t know. The problem is that there are decades of experience on making great code, but much less so on how to make software that is great for our users.

It’s made worse by the fact that for most of us, the code is invisible to our bosses/clients, but as soon as you can see or touch or use something, everyone thinks that they’re an expert on How Things Should Be Done (and often decisions are made not on the basis of expertise or empirical data but by HIPPO).

Kathy Sierra’s new book BADASS: Making Users Awesome gives us down in the trenches a set of tools to both understand the attributes of software (or any designed product, I suppose) as they affect our users’ successful usage of them, and how to structure our systems such that they enable, facilitate, and eventually draw our users toward their own incipient awesomeness.

Why It Would Be Easy To Discount This Book

The author was one of the creators and authors of the old O’Reilly ‘Head First’ series of books, which you may remember as programming books from O’Reilly that had photos of humans on the cover instead of line art of cool animals. I think it was easy at the time to dismiss those books out of hand because a) I was already a professional developer, and books aimed at beginners were by definition not interesting b) instead of imposing blocks of Very Serious Text, these books used stock photos of people with little cartoon voice bubbles and diagrams that don’t look like the diagrams in every other programming book.

This book follows that style, and it’s very easy to flip through the pages and decide that because it doesn’t look like a serious book, that there’s no reason to take it seriously.

Why That Would Be A Mistake

…it turns out that Sierra is using the techniques described in the book to structure and write the book itself, and that those techniques have solid research and science behind them (and she’s great about providing citations to the literature for those inclined to pursue things in more depth).

Sometimes people do things differently because they’re different, and sometimes because the new ways work better.

The Premise

No one uses a piece of software because they really want to get good at using that software (perhaps you could argue the case that this isn’t true for games, but we’ll ignore that for now). Your users use your software because they want to be good at whatever real-world domain your software works with. As an industry, we do a horrible job designing software that takes a user from novice through to expert and works well for all users at varying points along that path. We’re great at designing dumbed-down software that users outgrow quickly, and pretty good at making software that you have to work at or fight with to gain any kind of proficiency (I cried in third grade learning long division, and getting good with vi was less pleasant than that).

Sierra’s book looks at the nature of expertise, how people gain skills, and how gaining those skills in the right way is itself incentive to continue learning and incrementally gain expertise. In the last few years there’s been a lot of talk about using Gamification to incentivize our users, and she explains clearly why slapping a lazy game/reward system on top of bad software like a layer of spackle doesn’t work, and more importantly, how to build systems that actually provide payoff to your users along the way.

The Real Payoff

In an ideal world, this book would gain the kind of toehold among developers that a book like the old Gang of Four Design Patterns book did, giving us a new shared vocabulary to talk about some important issues. In that world, the stakeholders and decision makers would also pick up a copy and at least thumb through it enough to authorize the development of increasingly better software, built by developers who understand how to craft their systems to help their users become awesome. That’s the kind of arms race that I could get behind.

Brett g Porter

Brett g Porter

Chief Engineer, Development Practices at Art & Logic. Always looking for excuses to write code. Tweets at both @artandlogic and @bgporter.
Brett g Porter


Music + software + music software + ice cream. Relapsing composer/trombonist. Also creator of @tmbotg. Day job @artandlogic
Looking toward home - 12 hours ago
Brett g Porter

Latest posts by Brett g Porter (see all)


Creative Commons License

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.