Many discussions about user interfaces see the same type of arguments. Developers like complicated things, with many things on the screen. Designers like pleasant esthetic experience. This problem can be addressed with usability testing.

Many sites have usability problems, including Steve Krug’s own site. Steve hasn’t fixed the problem, because it’s cheaper to send an email in support of a struggling user than to fix the actual problem. You don’t have the resources. Easy to find, but hard to fix.

Steve makes the argument you should do the usability testing yourself. Most sites aren’t tested, because it costs money, time, and it’s hard to find professionals to do it. So Steve will show how to do it yourself.

Do-it-yourself usability testing

• Three users per round. That should be plenty, you’ll find more than you can fix.
• No lab or mirrors. Use screen sharing so the dev team can watch (gotomeeting)
• No elaborate recruiting
• Record the session with Camtasia or the more elaborate Morae, or CamStudio.
• No stats, no exit questions, no faux validity.
• No big report. Just debrief over lunch, right after the session (which should be one morning per month or something). Make a bullet list email at that time, with the problems that you need to solve.

Live demo test

Next is a live usability test of the SXSW schedule website, since we all know that site. Steve reads the test script out loud to the volunteer, verbatim, which he recommends. Download it from his site.

Tip: read the test out loud for the volunteer, and give him the written test. That way you can be sure he has read everything. Take a look at this demo test to see how this works.

Your job guiding them is to keep them from being too frustrated. If they stay stuck, you’re not going to learn anything anymore. So ask: “what are you thinking” a lot. Then write down: What were the top three usability problems that you observed.

Tips from the book:

• Make the tests regular. Something like the third thursday every month.
• Start earlier than you think makes sense. You can’t do major changes near the end. So try paper versions at first, or test competitors, or sites that use the same design or functionality that you’re trying to implement.
• Recruit loosely. Finding the ‘existing customers’ is much harder than you think.
• Make it a spectator sport. Get many people to watch the test. Get a good microphone and speakers, can be cheap USB things, work well. And spend on the best snacks!
• Focus ruthlessly on a small number of the most important problems. You will know what the killer issues will be. Fix those first. You will have 9 issues (3 per person) in the debriefing session, everybody should then pick their top 3 worst problems. Then take the top one, plan what you need to fix that one. Then the second. Etc.
• When fixing problems, always do the least you can do. What is the smallest tweak that we think would solve the problem? It’s not the perfect solution, but this may solve it. Don’t redesign, but tweak. There are many reasons why tweaks are better than redesigns.

Useful session, basically summarizing his book, go to http://peachpit.com, and use the discount code SXSW2011.

And that’s a wrap!