Charles Rowe dot com

Coding Horror posted an article about User interface that was based on a interface usability post by Tantek Çelik.
Between the two posts, the clouds parted and I was struck square in the face with an epiphany. The way I view interfaces has changed for the better. I have come up with 5 of my own items to extend Tantek’s line of thought.

Tantek listed three solid points:

1) Human Interface cognitive load is proportional to the number of clicks/keystrokes

Basically, the more interaction required to complete a task, the more difficult it becomes. This is a very elegant way of explaining the increasingly common problem of cramming as much functionality as possible onto the page real estate. Think of it like coffee…if I ask for a coffee, I want a coffee flavored coffee. Don’t make me go through the list one at a time describing flavor, size, temperature, type of sweetener, type of dairy product, etc, etc. If the user wants something other than a coffee, they will ask you specifically. Ajax hasn’t helped the problem. Now people are building “up” as well as “out”.

2) Human interface cognitive load is proportional to interface latency

The longer the user has to maintain interest and concentrate on completing the task at hand, the more the usability of the interface will decrease. Keep your application responsive to keep the user’s attention on the task at hand.

3) The usability of an interface is inversely proportional to its cognitive load

The more a user has to “work” to operate an interface, the more it loses its effectiveness as an interface. This is another obvious one, but keep your interface intuitive. I like to think this rule also covers higher level flow and navigation as well. It is easy to imagine the first person to realize this rule was probably the same person to coin the term “voice mail hell”.

Running with Tantek’s points I think I we could extend his list with some other usability design suggestions:

4) Don’t break user expectations

The user has a set of tools they are familiar with: back buttons, refresh buttons, bookmarks, etc. As a developer and designer, taking away their known tool set is decreasing application usability. In the AJAX world, I think Gmail holds to this rule very well. If I remember correctly, they use the frame & refresh method to maintain browser functionality. As GregMagarshak points out in Codinghorror comments, this rule could be as simple as insuring double submits don’t occur on basic form data when the back button is used. Duh! It is obvious, but I think Greg hit the nail on the head by pointing out this oft seen form killer.

5) Error pages cause friction

Having users encountering form errors was never part of the critical path to completing a task within an application. Nothing kills an interface faster than delivering errors one or two at a time to the user. Anything that can be done to get them out of the error correction loop faster will help insure strong interface usability. I think validating real time (such as with javascript) is a very elegant way to keep the user task oriented. Just don’t forget that going the javascript route requires thedata be validated twice.

6) Let the user have some say regarding colors and design.

Everyone likes being able to customize their stuff. Besides aesthetics, there is a functional element to customization because it can have a direct impact on usability. the color blind and the elderly (both a significant portion of the population) will also appreciate the gesture. Amusingly enough, I ran into this situation in my current project: The elderly SME can’t see the “normal” color set that the developers use. On the flip side, we have lost 2 developers when they accidentally looked at the SME’s color set and burned out their retinas.
Murch had a valid point stating: “Older operators need higher brightness levels to distinguish colors”.
Just don’t subject the rest of the user base to those brighter (blinding?) colors

7) Don’t expect users to read instructions

Users are more likely to fumble around an application than they are to use the well laid out help system. When the path analysis report looks like a muddy football field instead of following the critical path from the design specifications, there is a usability problem. Applications need to have an interface that is familiar to their target users or they will spend too much time learning and fighting the interface instead of the tacking the problem the application was designed to solve. This doesn’t mean you forgo innovation. Innovation introduced slowly in a familiar environment will build user confidence in the usability of the interface. You could even apply the customization rule and offer different interface modes (such as beginner and advanced) that allow the user to pick and choose what is intuitive for them.

8) Keep your public facing system clean.
Nothing mangles usability quite like a system error. With a little bit of preparation you can minimize the damage:

• 404 error? Make your own 404 web page. Offer some important jump points. Let the user know the help desk has just received an email that they experienced a problem.
• Run time error with your scripting language? Roll your own error handlers or use exception handling. Even if there is a bug in the code, a user who sees you gracefully handle and report the error will have significantly more confidence than if they were to encounter “semicolon missing at the end of line 74”.
  Most users don’t want to “break” your system. Users quickly get fed up when they feel a need to tiptoe around an application. Handle the system errors yourself and show them you have it covered. You can even do one better and offer a humorous “thank you for justifying the help desk budget” on the error page :D.

This entry was posted on Wednesday, May 23rd, 2007 at 7:18 am by Charles and is filed under development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.