Book summary: Don’t make me think by Steve Krug / part 2
…this is a continuation of Don’t make me think summary part 1.
Key idea 6
Don’t rely on friends or coworkers to evaluate your website. Test, test and test again.
So your website should be easy to understand and navigate. But how do you ensure that your final product actually fulfills these goals? You might think to ask your friends, or simply trust your own judgment.
Unfortunately, you can’t rely solely on your own judgment. After all, you’ve built the website, so its awesome features and usability flows are obvious to you. It’s impossible to be objective!
Having discussions with friends about the site will be similarly fruitless. Because ultimately, people have wildly subjective opinions about what a website should be.
If you ask a designer, they’ll tell you they like beautiful pages with lots of white space and subtle touches that offer a pleasant visual experience. Meanwhile, a developer would prefer to see a site with lots of innovative features that a visitor can fiddle around with. And both the developer and designer will assume everyone shares their views.
We’re all like this! Whatever we like in a website, whether it be lots of colorful images or stark minimalism, is by default anathema to someone else. And few people try to see things from another point of view; we just assume that we’re “right.”
But in fact, there are no “right” or “wrong” answers in web design. And that’s why asking a couple of people for their opinions simply doesn’t work.
So instead, conduct tests. Watching people trying to navigate your website is the most objective way to evaluate what you’ve built and to figure out whether your website is working the way you intended.
Testing is also valuable because it removes the categories of “right” and “wrong” and shifts your attention to what is and isn’t working. What’s more, it shows you just how different web users are!
Key idea 7
Watch people navigate your site to see where and how they fail to make sense of features.
Although testing is necessary, it doesn’t sound like a lot of fun to most people. That’s why you should be sure to offer compensation or special treats to test subjects (developers are particularly fond of pizza, for example) to ensure as many people as possible will test your site.
Your website should be understandable to anyone regardless of background, so don’t worry about selecting subjects only from your target audience. Any sort of person will do; just remember to reward your testers for their help — by paying them for their time.
Once you’ve selected a group, ask them to navigate your site while either you or a facilitator (someone patient and empathetic) watches and takes notes. One of the facilitator’s goals should be to keep the user focused and comfortable.
Start with the home page. Have the tester click around and talk about what she’s seeing. That will give you a sense of whether she’s getting the main idea of the site. Ask questions such as, “What are you thinking?” and “What are you looking at?”
But make sure you’re not influencing the tester’s behavior. If she asks for help, say something like, “What would you do if I weren’t here?”
Get your test group to try out every feature on your site, including logging in, creating a profile or returning an item. If a tester fails at a task, watch her try to resolve it and then let her keep clicking until she either becomes too frustrated or you realize you can’t learn anything else from the session.
An important tip is to get managers, team members and other stakeholders to watch the testing process with you. Often people don’t see the point of testing, assuming the website is good enough.
But watching someone fail to use a website can be a transformative experience, making executives for example start taking usability seriously. In all probability, the next words out of a manager’s mouth will be, “Why didn’t we do this earlier?!”
Key idea 8
Testing doesn’t have to be resource-intensive or time-consuming to produce useful insights.
Many web development teams avoid testing because they assume that testing involves a lot of time, money and expertise. But that’s not the case.
After all, you don’t need to test hundreds of people. You’re not conducting a scientific study, or trying to produce statistically significant results; you’re simply trying to inform your decision making and understand where people might struggle on your site.
To that end, you only need to test three normal, everyday web users and have everyone observing the testing process take notes on the top three problems that frustrate or confuse participants.
In the author’s experience, you’ll always encounter more problems than you can reasonably fix. Thus, you’ll have to prioritize and focus only on things that need fixing.
In other words, don’t worry about fixing problems a tester quickly recovered from on her own. These minor obstacles are part of the fun of exploring a new website.
Another benefit of keeping your testing group small is that you can start the process earlier, which makes testing that much more effective. The earlier you find problems, the easier it is to implement changes.
Just consider how much easier it is to adjust a beta site than one that’s already established, intricate and live! (Additionally, you won’t have to explain or justify changes to users familiar with a long-running website.)
You can also start testing before you’ve even built a website, by watching people navigate competitors’ sites. That way, you can generate useful knowledge that will inform your own development process.
Ultimately, by conducting testing early on, you can make better decisions throughout the development process. And this saves time, as you won’t have to redo everything at the end. All it takes is a few hours of time and a little bit of cash upfront.
Key idea 9
Make sure your site’s mobile version loads quickly and prioritizes in-demand features.
Do you remember the pre-smartphone era? Even then, some cell phones had web browsers, but they were underused. It wasn’t until Apple introduced a touchscreen with swiping and pinching features that mobile browsing became so widespread.
Today, people move faster and read less online; what’s more, they’re more likely to leave a site as soon as they run into a hiccup. Don’t forget that mobile download speeds are unreliable and performance varies widely — so make sure your site loads quickly.
Your design also has to accommodate a smartphone’s small screen. Since you have less space to convey the same amount of information, you’ll have to make compromises.
Prioritize to ensure that in-demand features are quickly found. The rest of the information can be a few taps away, just as long as it’s obvious to a user how to get there.
Another important thing to note is that people use the internet everywhere and want to do everything on it. It’s a common misconception that people only use a smartphone on the go, and thus only need basic functions. The reality is that a user is just as likely to be sitting on the sofa at home while surfing on a smartphone, and will thus expect to access a site’s full menu of features.
That’s why you should always provide a link to the complete website and implement zoomability features. Returning visitors may be accustomed to your website, so they may not need to see an entire page to figure out how to navigate.
All in all, mobile computing is the future, and new possibilities for online interaction will provide amazing opportunities to create a great user experience.
Just remember that the only way to make sure you’ve built something usable is to test it!
Usability puts a visitor front and center, ensuring that it is as easy as possible to find information on a website. You can ensure that your website is delivering a great user experience by conducting simple tests at every stage of the development process.
If usability testing bores your boss, do it on your own time.
You don’t have to invite the whole executive suite to your first usability tests; the first steps can and should be simple and informal. What you need to do is to show exactly how testing can yield fruitful insights. You could, for example, measure the number of incoming support emails after you’ve corrected a mislabeled button; then send the data to your boss, along with a video of the test that initially drew your attention to the issue.