I finally read Don’t Make Me Think by Steve Krug. I have long believed in the title of this book as many web applications are much harder to use than they should be. When arguing about usability, I always tell people “pretend that I am an idiot” and then you can talk about real usability design changes. I am not sure why it took me so long to start reading Krug’s book, but I am glad that I did. Mainly, some of my basic “idiot rules” were talked about in his book.

The first two Krug rules of usability are very related:

1. Don’t make me think – as far as is humanly possible, when I look at a web page it should be self-evident, obvious, self-explanatory.
2. It doesn’t matter how many times I have to click, as long as each click is a mindless unambiguous choice.

The basic idea is, assume the user is not internet-savvy, and design the site in a way that makes it easy for them to click the right things. Krug is also throwing out the 3-click rule, but admittedly you still can’t have too many clicks between the start and the goal.

If you do read the book, keep in mind that a majority of the book is focused on ecommerce sites. Although much of the design advice makes sense for almost every site, regardless of industry. In particular, I believe that many internet startups should be paying attention to much of the book. The rest of this post, focuses on how to use Krug’s advice for the new breed of internet applications.

What Am I Supposed To Do Now

So, someone navigates to your site. Do they have to ask the question “What the hell do I do now?” If so, you have a usability problem. I have been guilty of this before, and it is one of the most distressing problems you can have. “My home page is unusable! What does that mean for the rest of my site?” For better or worse, users probably won’t get to the rest of your site. Krug believes that everything should be self-explanatory. For internet applications that is not so simple, but Krug does have some advice regarding instructions and text on your pages. When you are done creating a page with a large amount of instructions, delete half of the text. Once that is done, delete half of the text again. If you were verbose before, you should have a very concise description of what the user should do.

Twitter started with very little instructions, and this worked in their favor. First, “what are you doing” is a question that anyone can answer. The second benefit to the lack of detailed instruction was that users made the service into whatever they wanted. This is not always possible, but see if your application can benefit from the same ideas.

Krug mentions that the home page needs to answer four questions. The first three are obvious, but the fourth is one that startups need to focus on, “Why should I be here and not somewhere else?” If your users can’t answer that, you may have more than a usability problem. An important corollary to this should be “Is this site easier to use than others?” If your startup has a number of competitors, sometimes functionality is difficult to differentiate. However, if your site is easier to use, that could be the difference between failing quickly and having the ability to survive. Take a look at the personal finance industry. Quicken has been around for years and did eventually put their product online. Mint and a few other startups decided to compete with them. There is very little you can do to differentiate personal finance sites, but Mint was the clear winner, and this became obvious when Intuit purchased them. Why was Mint the winner? Usability. They made personal finance much simpler to maintain, goals and budgets were simpler to setup.

What Are You Arguing About

Disappointingly, usability is very subjective. Because everyone uses online applications now, they all feel like they have an expert opinion on some topics, myself included. Arguments happen, but the question is what are you arguing about? Krug has an excellent example of what to look at when silly arguments start regarding some basic web design ideas:

It is not productive to ask questions like “Do most people like pulldown menus?” The right kind of question to ask is “Does this pulldown, with these items and this wording in this context on this page create a good experience for most people who are likely to use this site?

What Krug is really saying is that guidelines and rules are useful, but they might not apply in a specific context. The general rule used to be that you put dropdowns on your forms whenever users needed to select from a predetermined list of acceptable options. Sometimes these lists can get very long. When AJAX started to get popular, people started using auto-complete text boxes instead of dropdowns. This is because people are comfortable typing what they think should appear and seeing a list of suggested options, especially if the list of options is going to be long. Google has continued to make auto-complete (or auto-suggest in their case) a huge part of their main search page.

Even if you have followed all of these guidelines, users will eventually go astray. What do you do then? At first, nothing. You need to figure out how big of a problem something really is. Krug provides us with excellent advice again:

As long as (a) everyone who has the problem notices that they’re no longer headed in the right direction quickly, and (b) they manage to recover without help, and (c) it doesn’t seem to faze them, you can ignore the problem.

There are many examples of this type of behavior. Search is designed to ensure that it is easy to recover from a mistaken choice. Ecommerce works in the same way with related product widgets. Many web sites try to help by providing breadcrumbs based on the navigation history. All of these methods are useful ways to help a user recover from going the wrong way.

So, if you are a web designer, you should own Krug’s Don’t Make Me Think already. If you are a software engineer in a web site or web application company, I would still recommend that you read the book. If you do not know why some UI decisions are made, you will not know how to design your API or your web services. If you can make the web designer and web programmer’s lives easier, you can help them make a site more usable. Even product managers should read the book to help them decide how new features get integrated into an application without making the application look cluttered. In reality, almost anyone involved with web sites and applications can find some benefit from the book. I was just glad that I can stop saying “pretend I am an idiot”, and now I can just point people to a book.

Disclosure: All links to the book are Amazon affiliate links. That means if you buy something, I make a few pennies.