Notes about the Don't make me think

This is not my kind of book. I usually read books about programming. But the beginning of the book was quite funny. Steve Krug dedicated the book to the woman who laughed so hard while reading this book that milk came out of her nose. 

Introduction - Read me first

Krug wrote this book for people who cannot afford to have an usability expert in their team. The book is short on purpose - it is more likely it will be used. Krug's definition of usability is: An average person can figure out how to use the thing to accomplish something without it being more trouble than it's worth. This is quite similar to how readability is important when programming.

Chapter 1 - Don't make me think

This is the first Krug's law of usability. The things we create should be self-evident, so the average people could immediately tell 'Oh, that's a ____'. If you can't make something self-evident, you should at least make it self-explanatory. This reminds me of a Screaming Architecture from the Clean Coders blog.

Typical things that make us think are cute or clever names, marketing-induced names, company-specific names, and unfamiliar technical names. This advice can be also applied to naming variables, method, classes, etc. during programming.

Chapter 2 - How do we really use a Web

Users usually glance at a page, scan some of the text and click of the first thing that catches their interest or vaguely resembles what they are looking for. If our audience is acting like we are designing billboards, then we should design great billboards.

Chapter 3 - Billboard Design 101

We should rely on conventions most of the time. We should only invent something new if we know for sure it is better than the convention. But clarity trumps consistency. If we can make something clearer with a little inconsistency, we should. This all applies to programming as well.

There are couple of rules for visual hierarchies. The more important something is the more prominent it should be. Things that are related logically are related visually. Things are "nested" visually to show what is part of what. It is important to divide pages into sections so that users can safely ignore what does not interest them. These rules seems also relevant in programming. 

When editing a page, we should assume that everything is a noise unless proven useful. 

To support text scanning, we should use plenty of headings, keep paragraphs short, use bulleted lists and highlight key terms. 

Chapter 4 - Animal, Vegetable or Mineral?

Krug's 2nd law of usability: It doesn't matter how many times I have to click as long as each click is a mindless unambiguous choice. Three mindless unambiguous clicks are equal to one click that requires thought.

Sometimes we need to guide users. The guidance then should be brief, timely and unavoidable. 

Chapter 5 - Avoid needless Words

Krug's 3rd law of usability: Get rid of half of the words. Then get rid of half of what is left.

We should get rid of happy welcome talk at the beginning of the page. We should avoid instructions as everything should be self-explanatory. This can be transformed for programmers into "minimize needless documentation" advice. 

Chapter 6 - Street signs and Breadcrumbs

Web navigations should better be good. Most users expect the site ID directs them to the home page. Every page needs a name. The page name should be in the right place and prominent. The name of the page should match the link I clicked to get there. The trunk test:
  1. Print a random page of the site.
  2. Squint so you cannot really study it closely.
  3. As quickly as possible try to find: Site ID, Page name, Primary and Secondary navigation, You are here indicators and Search.

Chapter 7 - The Big Bang Theory of Web Design

The Home Page has to accommodate the site identity and the mission, site hierarchy (through navigation), search, teases, content promos, feature promos, timely content, deals, shortcuts, registration and more: show users what they are looking for and what they might look for, where to start and establish credibility and trust. The problems of home pages are that everybody has a opinion about it and it should serve very diverse interests. Any shared "commons" will be destroyed by overuse. This observation applies to programming as well.

The home page needs to answer 4 basic questions - What is this site? What can I do here? What do they have here? Why should I be here and not somewhere else? We shouldn't state the mission statement in the welcome blurb and it is the one of most important things to test. Good taglines convey differentiation, ideally nobody else in the world could use it but you. 

Chapter 8 - The Farmer and Cowman should be Friends

All web users are unique, there is no average user. There is only one way to answer religious usability questions - testing. 

Chapter 9 - Usability Testing on 10 Cents a Day

In usability tests you watch people use a product instead of them talking about it (that's focus groups). If you want to make a great product you have to test its usability. One usability test is 100% better than no test. Testing early is 50 times more useful than testing later. You just watch some people use your product and note where they run into problems. You should test at least one morning a month with 3 people. The people should be recruited loosely and graded based on the curve. You test in quiet place. Almost anyone could facilitate testing, the person should be patient, calm, empathetic and a good listener. As many people as possible should observe, in the background. It is never too early to start with usability testing. We should test everything the team produces. What happens during the test?
  1. Welcome (4 minutes).
  2. The questions (2 minutes).
  3. Home page tour (3 minutes).
  4. The tasks (35 minutes).
  5. Probing (5 minutes) about the tasks.
  6. Wrapping up (5 minutes).
Typical problems you will find - the users are unclear about the concept, or the words they are looking for are not there, or there is too much going on. Focus ruthlessly on the most serious problems first. Most of the advice for usability testing applies to unit testing as well. Do it often, do it early, etc. 

Chapter 10 - Mobile

There is not much mobile-specific. The principles are the same. You should make a good tradeoffs. There was a Mobile First pattern which was a great idea at first - to think carefully what you really need to display on the page. But then it got messed up with designers designing according to what they think people do on mobiles. Managing real estate problems should be done at the expense of usability. We should allow zooming and let users use the full version of the site. Don't overuse hover. Mobile apps need to be learnable, effective and efficient. Computers can never be too fast. Mobile usability testing requires a camera pointed to the device screen instead of screen mirroring, maybe attached to the device. Don't bother with recording the participant. 

Chapter 11 - Usability as a Common Courtesy

Users have a reservoir of their goodwill. It is idiosyncratic and situational, you can refill it and sometimes a single mistake can make it empty. Typical mistakes are hiding information users need, e.g. phone numbers, prices, punishing users for e.g. formatting mistakes, asking for information you don't really need, etc.

Chapter 12 - Accessibility and you

Accessibility is the right thing to do. The low-hanging fruit: add appropriate alt text to every image, use headings correctly, make forms work with screen readers, put a skip to main content link on every page, make all content accessible by keyboard. 

Chapter 13 - Guide for the perplexed

Don't use small, low contrast type. Don't put labels into form fields. Preserve distinction between visited and unvisited text links. Don't float headings between paragraphs. 

Comments

Popular posts from this blog

Notes about Clean Agile

Notes about The Pragmatic Programmer

Notes about Monolith to Microservices