Don’t Make Me Think: The Workshop, with Steve Krug – Notes and Opinions

Chicago, September 30, 2005
Notes and Opinions

It’s unbelievably hard to get rid of all of the usability issues on a website. Our capacity for finding usability problems usually exceeds our resources for fixing them, so we’ve got to shoot for the biggest ones that affect the most people and try to keep ahead of the curve.

But how do you identify the biggest ones? What’s an expert’s opinion on the most important things to get right? How does that apply to my site? I went to this seminar with precisely these questions, and wasn’t disappointed.

Disclaimer
Just about all the information presented here is copyrighted intellectual property of Steve Krug. I’m just writing out my notes on the stuff. Text in italics are my own comments added after having taken notes.

Topics covered at the workshop really jumped around a bit, so I’ve re-organized my notes to keep topics somewhat together below. That should explain some of the disjointed flow between sentences/bullets below.


On Graphics/Colors

  • Some people are “icon dyslexic”; so try to spell out options instead of using icons. There are very few identifiable icons that people can reliably recognize.
  • Pictures actually draw your eye to the text next to it, more than to the picture itself. It would follow then, that a picture that’s always changing (flashing, almost) would draw your eye to the text, then away, then away again, etc. Which is why I should get rid of the flash jpeg rotator on the company homepage. emoticon
  • Anything on a page that moves fast or constantly makes some people crazy. Usually better to show only one image when you’ve got several you want to, and pick it randomly for each page view. It helps keep the site looking fresh as they keep coming back, and isn’t moving to drive anyone crazy.
  • If more than half of the people look at your site colors and describe it as “puke”, pay attention. Otherwise ignore them. Color is a personal opinion thing.
  • Make sure text is legible: Don’t pick an obnoxious font and make sure contrast between the text and background is high.

On Working With Programmers (or: “There’s No Way To Do That”)
Agree with them that a desired functionality is impossible, and leave it at that. Programmers, who love solving challenges, usually find a way.

For example, showing shipping info before asking for an address.

“Programmer’s point of view: You have to know where it’s going to get an accurate price to show.”
“User’s point of view: I don’t want to give my personal information until I’m sure I want this, which is affected by the options for shipping it to me.”
It’s nice when a site shows you an average, or base rates and lets you customize the price with your address, if you want to.

As a programmer, I have to agree with this approach. I love solving problems, but don’t always think of things form outside my own point of view, so I don’t recognize them.

On Forms

  • Instructions need to be where they’ll be seen.
  • They need to be exceptionally short: Sentence fragments are ok.
  • Instructions that are too long will be ignored, not read.
  • When instructions are too long (daunting) people will just start clicking (Muddling through is a very popular and effective strategy).
  • Instructions that are far away from the object are not very useful.
  • Ideally, instructions should be on the object/button/field, i.e. <button>Save This Form</button>
  • Pull downs (drop boxes/select boxes) are one of the “if”-ier things on the web. If you have space, just show the list. They’re hard to multi-select from, etc.
  • Don’t ask for any information that’s not absolutely required.
  • Make sure link color & headline colors are different – or they’re confusing.
  • Make sure required fields are clearly marked.
  • Make sure errors are obvious.
  • Make sure that if an interface doesn’t change between screens, and an error occurs because of changes made to statically positioned element, that IT indicates what the error was – because that’s where your eyes are likely to go back.
  • Accept any format of data the user might type. Phone numbers can have any character in them (parentheses, dashes, spaces, dots, etc). The string replacement to boil that down to a usable bit of data for your database is negligible compared to the grief you’ll cause a user when they can’t cut & paste the number they’ve already got.
  • If you’ve got a form with the phrase: “Fill in the fields below and click submit”, and a user actually needs those instructions to complete the form, you really don’t want that user as a customer. Their own ISP probably required them to fill one out, so you don’t need to educate them on something so simple.

Layout, Graphics, Order

  • Users stop reading at the first line that looks like what they want — they can always hit the back button. This is why you should design for billboards @ 60mph instead of for great literature worth reading.
  • If you’ve got an element on the right side of the page, or that looks like a banner at the top of the page, in a box, especially with a graphic: it looks like an ad.
  • If it looks like an ad, it will be ignored like an ad.
  • Notice how Amazon’s “Order” (Proceed to Checkout/Add to Cart/Buy Now, etc) button is the brightest thing on the page. Even their “important message” box/text isn’t as graphically noticeable. But since the “important message” is near the top of the page and pushes all the stuff you need to use down, it’s still noticed without detracting from the option to give them money.
  • “Contact us” isn’t as important as Home, etc. Move it to secondary navigation or utility navigation.
  • Design for 800 width. Columns fixed right of 800 are considered ads.
  • Stakeholders always want more stuff, and have pervasive and disastrous influence on design.
  • Liquid vs. fixed doesn’t matter – it’s only opinion. Nobody will avoid your site because it doesn’t fill his or her screen – but they won’t bother looking at content past the horizontal “fold” (assuming its an ad).
  • If you use tabs, have a Home tab selected by default. It introduces users to that mindset. Selected tab should be a different color from others.
  • If there’s top navigation & side navigation, what’s the difference between them? Is side navigation “sub” navigation? It’s confusing if they’re obvious not Hierarchical. Don’t confuse utilities & secondary navigation.
  • Inconsistency between the top or side navigation in different versions of the site (i.e. logged in or not logged in) is hurtful.
  • Bold face subtle differences between similar texts if they’re near each other.
  • A 3-line paragraph at the top of a page (i.e. instructions) is too long. Better is 3 paragraphs that are each short. People will skip a paragraph to look through list items and click without even knowing what they’re going into.
  • On navigation pages:
    1-sentence paragraphs are good.
    2-sentence paragraphs barely ever get read.
  • 2 Shorter paragraphs are more readable than 1 longer, even if the total word count is the same.
  • If navigation is visible it needs a “you are here” indicator that matches the name & title/headline on the page (including top navigation & side navigation).
  • There’s not really a problem with info duplicated in 2 places if it’s likely to be looked for in both (not sure if he was talking about navigation or content here).

Show Me The Error
Whack your users over the head with an error message. Make it bright, bold, obvious.

On Web 2.0
Design experiences carefully: a problem with AJAX sites can be that it happens so seamlessly that a user doesn’t know anything happened.

Test, Test, Test!

  • When do you test? Show someone(s) the first napkin sketches and ask them “Tell me what you think this is/does.” Even their earliest answers will tell you if what you’re doing is working. The earlier you get feedback, the better.
  • When you’re considering changing a process on your site, test another site already doing it, instead of building out your own. You’ll save time and money, and this helps inform your own dev decision.
  • Don’t test 2 versions of a site against each other – you test the slightly better one only and only the 2nd if there’s a problem with that first one, revealed in the testing.
  • Recruiting users only from your target audience only makes it harder to find recruits, and less likely you’ll test often.
  • Testing non-audience recruits often is better than testing in-audience recruits once.
  • Get a mix of testers who know what they’re doing business-process wise (but not on the site) and people who don’t know either — both will reveal valuable information.
  • Tester qualifications: experience with a web browser, not familiar with the site to test.
  • Test 3-4 users one morning per month. Tweak your site according to their feedback, and then test again (test different users – the first ones will be tainted by past experience). You’ll find 3-4 things like this per hour (per person, since each person gets about 45 minutes, with a 15 minute break for you).
  • There’s a point of diminishing returns in user testing. Even with just 3-4 users, you’ll start getting the same feedback. If you did more, you’d probably just keep getting the same feedback, but spend more time and money (you have to reward them somehow) on it.
  • Debrief after watching the tests, discuss what to tweak with developers.
  • Focus groups are not usability tests. They’re about opinions, not actions. People are unreliable reporters of their own behavior. User testing is not asking for group opinion — it’s watching/talking to an individual user.
  • Usability test 1 person at a time, but do 3-4 in a morning/day. Sit them down for an hour each (45 minutes) with a break for you between.
  • Start with homepage impressions, even if it’s not what you’re testing. What’s on the page? What do they make of it, etc?
  • Try several tests, not a repetition of one task.
  • Ask them to think out loud. If they look puzzled at any time, ask them what they’re thinking. If they look puzzled after a click, ask them what they expected to happen, or what they wanted/needed.
  • Also, go through the same tasks on a competitor’s site.
  • Thank them. Pay them. Form of payment varies.
  • If affordable, hire a pro to do the 1st and train you on it.
  • Usability testing is a cycle: test-fix-test, in month-long periods.
  • Cubicle tests: sketch the form on paper first, have someone fill it out, thinking aloud. It reveals problems without building code. Highly recommended.

Choosing Tasks to Test:

  • What do you have available to show?
  • What worries you?
  • What’s crucial for you/users to succeed?
  • What are people likely to do?
  • Keep it real. E.g. “Order a book you’d like to have”. “Buy a cup holder under $35” is an unreal test – nobody goes to a site with that in mind.
  • Write the task down and read it to the user – stick to the script and don’t telegraph intentions or non-verbal instructions. Avoid using the words that will appear on the screen, but make it unambiguous.
  • Piloting the task will help. Doesn’t have to be a fresh user, just make sure someone else understands the task before you start testing it.

Testing Tools

Other Testing Methods

  • Contextual inquiry: Going and observing real users in their own work process, and interviewing them to gather early info.
  • Remote testing: use vnc. Loses facial expressions, but if you’re on the phone you still get audio. Not as good as in-person. Learn to do in-person testing first.

Eye Tracking Goodness?
Eye tracking is cool when you see the end result, but the hardware is restrictively expensive and hard to compile data from.

Reporting Test Results
Try to avoid long reports, if you have to do them at all. Only report the significant problems, and better to get execs to watch a highlight reel from the tests (disappointments). There’ll only be 1-2 things in a report that’ll grab people. Stats don’t do that. Stick to executive summary + video clips (linked).

Book Recommendations

  • Check out “Defensive Design For The Web
  • Check out Carolyn Snyder’s “Paper Prototyping” for how to do user tests with applications. This technique seems low-tech, but lets you test interfaces on paper before building it (low cost).

For more information, check out:

Conclusion
This workshop alone was worth the whole trip price for me — and as an added bonus, I got to attend Lou Rosenfeld’s seminar the day before, and have drinks with them both at the Happy Hour.

If you’re familiar with the “Don’t Make Me Think” book, you’ll know what to expect at the workshop. Get the 2nd edition of the book, by the way. Chapter 12’s “Help! My Boss Wants Me To ___.” is worth it. I was asked (just the day before leaving for the trip, actually) to “add some pizzazz” via flash/music, and this chapter gives expert testimony to back up your natural “Ugh, do I have to?” reaction.

I highly recommend going if you’ve got any questions about your site, about how to test, about how to rate your own site’s usability. Steve abbreviated some parts of his presentation to match our speed and interests, and looked at several of our own sites as object examples of better ways to do things, and how to conduct tests. He even offered to join conference calls for the other sites not covered during the day, so we could share the benefit of his brief testing with our co-workers (and bosses!). That’s worth the price of admission in itself!  [To be accurate, I need to report that despite several attempts to take Steve up on this offer, I’ve yet to hear from him.  Your mileage may vary.]
Really. Just Go To The Workshop. It’s worth it.

3 replies on “Don’t Make Me Think: The Workshop, with Steve Krug – Notes and Opinions”