Usability Testing in the Wild

When you test your product (software or otherwise), you should perform a usability test with people who share some characteristics with your user base. For example, when testing your new website, this characteristic can be "people who use computers". But you may have a particular feature that is very specific. In this case, you should probably test with a more representative group.

For example, your ATM design may include aids for the visually impaired. Your test group, then, should probably include at least one person who is, in fact, blind. This will help to avoid situations where it takes an actual user almost five minutes just to find a headphone jack. And posting a video of it on Youtube.

Ferret What Now!?

There are a thousand million different ways to make your website mockable. The very least you can do is make sure that your domain name isn't one of them. Remember that URLs are case insensitive. Also remember that while parsing words with no spaces, people mentally insert spaces between easily recognized words first. Try it yourself. Here are two examples.

• kidsexchange
• ferrethandjobs

If you're snickering right now, the very nice people at Kids Exchange and Ferreth & Jobs may take issue. I humbly request that you add the following Rule Zero to your website deployment checklist.

Print your domain name in all lowercase using a console font. Show it to five random people. (When using surnames as domain names, these people should not be relatives.) If three laugh, consider changing it.

The $300 Million Button

Someone asked me recently how to justify the expense of a usability test to those people who would need convincing. Stories like this one should help with that.

In Which Someone Else Makes a Really Good Point

Engineer Thinking, by Matt Legend Gemmell, is so full of good things that I really want to re-quote the whole thing. But I won't. Here's the penultimate paragraph that makes the broad point:

If you’ve exposed underling complexity or unnecessary choice in your software because you see those things as inevitable, it’s because your job isn’t finished. If you’re going to write GUI software for other people to use, do it properly, and treat those people like human beings instead of software engineers. If you want to expose complexity to the user and wash your hands of it, write command-line tools – or utilities that are used exclusively by other machine processes.

Push the button, Frank!

One thing that some interface designers sometimes overlook is button text. In a lot of contexts, buttons are given default values that seem "good enough". But consider your button text carefully. I'll give you the negative example that spawned this very thought process.

I'm installing a program with the standard Windows installer dialogs. There is some setup to do, and when it is finished, I'm presented with a screen that informs that everything is kosher and the install can commence. The default button that will kick everything off reads "Finish". Erroneous! I'm finishing nothing! Adding to surreal nature of the dialog is the descriptive sentence above the button: "Click Finish to begin installation."

"Click finish to begin" is going to be my new "get up to get down".

Verbs are good words for buttons. Buttons do things, and the word should describe what's going to happen. "Submit" is a popular, though vague, button word. "Cancel" is another popular one. In my example, the answer was staring the programmer right in the face when he wrote the description: the word should have been "Install", since that's exactly what's going to happen when the user clicks the button.

Give some thought to your button labels and make their purpose clear. If whatever IDE you're using provides defaults ... well, try to make it not to. Forcing yourself to fill in that text won't be a bad thing.

Order Up!

A quick note on form elements and tab ordering: if you are going to include links inside the form to provide more information on what a field is doing, you MUST unequivocally and without question, absolutely with no exceptions, positively set the tab ordering on your form so that those links are not included in the ever-popular keyboard shortcut of tabbing to the next item in the form.

Breaking the flow of "enter data - tab - enter data - tab" by highlighting help text interrupts the user's expectations, possibly to such an extent that said user will stop mid-form to write about it on his blog!

On Public Speaking

For my own future reference, and because it may interest others, here's an interesting post I found via Boing Boing today. Duncan Davidson's "Dear Speakers" - a few notes on public speaking from a man tasked with photographing talks and round tables and the like.