Best UX Books

I believe you can tell a lot about a person by what they read. These books will round out your UX education. 

Utopian Entrepreneur | Brenda Laurel
Two words: signed copy. She's my hero. 

A Web for Everyone: Designing Accessible User Experiences | Sarah Horton & Whitney Quesenbery
A website isn't usable if everyone can't use it. Also: the personas will change the way you think about people with disabilities.  

Observing the User Experience | Mike Kuniavsky
The ultimate handbook for user research, contextual inquiry, and usability testing. An excellent companion book is Measuring the User Experience by Tullis and Albert. 

Content Strategy for the Web | Kristina Halvorson
She gave credibility to what hundreds of writers, webmasters and user experience folks were toiling at in the background for years, making content strategist or content manager a "real" job. 

Search Analytics for Your Site: Conversations with Your Customers | Lou Rosenfeld
Another hands-on pick, but FINALLY someone tells the UX field how to use site search analytics for the betterment of society.  

Employees First, Customers Second | Vineet Nayar
Who is first in your company? It's a knowledge economy, and after reading this, you'll realize what so many agencies and corporations are doing wrong. 

HTML & CSS: Design and Build Websites | Jon Duckett
This book makes HTML and CSS easy for maintaining websites like mine and for trying your hand at UX prototyping with real code. It's a beautiful book that was written with its audience in mind.  

What, no TufteNorman or Nielsen? Yes, they are the UX literary canon, and yes, been there, done that. (Tog is my favorite, anyway.) 

Not asking "why?"

In a recent post, I listed a few ways that you can accidentally end up with a bad user experience. But there's another way to add bloat to your design: failing to ask "why."

The other day, a business analyst asked me to add a checkbox to one of my screens so that an administrative user could indicate, once every 6 months, that someone reviewed the screen for errors. Yet, we already have proof that the screen's data is being maintained because it's in the change log.


On the surface, adding a checkbox is an easy update to make. But, we don't know why we're being asked to make this update, or how this feature is going to be valuable to users. Simply put, our customer is requesting a solution without indicating what problem it solves. Though it might a good solution, how do we know it is the BEST solution?

Why ask why?

The next step isn't to drop the checkbox onto a wireframe, write up a few requirements, and head home for the weekend. The next step is to call up the client and ask "why."

  • Why does the client need this feature?
  • What information is the client hoping to collect via this feature?
  • How does the client plan to use this information?
  • Does the client know about the information we're already collecting?  

Once all these questions have been answered (and maybe a few more), we'll know how to proceed.

Needs vs. design

Good requirements describe a user need, but the need is never a "checkbox." The need is bigger. In my example's case, maybe the need is reporting for an audit, or maybe that checkbox is really supposed to notify someone of something. But we'll never know unless we stop and ask why, and solve the real problem.    

Mistakes were made.

And now, a note about imperfect user experiences and how I think they happen. (Think! Ha. This is how I know they happen, at least on my projects.)

The late-breaking requirement

The UX is perfect, things are going great, and you just finished usability testing. Then the client calls and asks you to add something. It's not a problem, it's just a small tweak. Easy! 

A few weeks later, you're looking at your screens and wondering how things went so wrong.

Daniel Kahneman would blame it on a lazy controller. Basically, your instinctual mind makes a snap decision based on previous experience and your analytical mind blindly follows. Most of the time, this works well. Other times, not so much. Maybe you were rushed, or didn't quite understand the full impact of the change. Either way, once you look at your design change with a fresh mind, you can see what you would've done differently.

The early design that overstays its welcome

The other good time to unwittingly make a mistake is early on. You make a solid choice based on the information that you have at the time. But as you refine the design and learn more about the project, this "solid choice" becomes irrelevant or even totally unnecessary.

You, and probably the larger team, have gotten used to seeing it, and you have a type of "banner blindness" to your own work. And maybe it's so irrelevant that usability testing won't uncover it, because it literally is useless and unremarkable.

Much later, you or someone on your team notices it and you see it for what it is - clutter.

How to fix it

These types of unitentional mistakes get shipped to customers and handed off to clients all the time. Sometimes, you only notice them after your engagement has ended. If you're still working on the project, offer to clean it up as part of a larger group of updates - they can only turn you down. There is rarely a good argument against continuous improvement.

If your project is still underway - just suck it up and admit that a part of your design needs rework! Maybe your team will have a better idea, or maybe they will remember something about the requirements that you've already forgotten. Most people understand that it is hard to self-critique, and I think they'll appreciate you more for your willingness to make a change.

How to keep it from happening

Don't work in a silo! Ask for opinions from other smart people as you're designing, whether they are on your team or not.

For those small late-breaking changes, it's tempting to do something quickly, call it done, and post a file. Instead, make the change and let it rest a few hours. Then you'll be able to review it with a more critical eye.