Bless their hearts award #09-2

Scenario
I needed to change my e-mail client password for the 16th time and for the 16th time could not figure out where to do it. So I went to Help. I searched on "password" and clicked the first topic in the list, named "Change Password." My expectations were high. I got this:



There is not a lot to changing a password, and the Change Password screen in this application is very well designed and easy to use. (It even tells me the rules for an acceptable password.) The only reason I can think of someone going to Help for "Change Password" is exactly the scenario I was in, namely, where do I do it?

Lesson learned
Three good rules for user assistance:

• Don't document the screen.
• Don't document the task.
• Do document the probable information gap(s) that could stop a user.
  

Collaborative Walkthroughs

A quick shoutout to Miranda Bennett for her blog http://www.mirandabennett.com/onwriting/?p=23 on collaborative walkthroughs. Can't afford usability tests, team building exercises, or training for your writers? Try these walkthroughs and see if you don't get addicted.

Works as designed--
I did a webinar yesterday for STC on pattern language for managing usability knowledge. Every now and then I listen to myself during these presentations and hear something in a new way. Yesterday was one of those moments for me. What I said and what I understood with a renewed clarity was that any usability problem can be described as a mismatch among the following three forces:

• What the user wanted to accomplish
• What the user did
• How the system responded

I can now see a strong parallel with John Carroll's definition of the human-computer system as comprising the the user context, the user interface, and the machine's architecture. It is the first item in these two lists, essentially the user goal, that drives the difference between "works as designed" and "this is something we've got to fix."

As an example, I did two searches this week where I misspelled the term I was searching for. One engine returned the message "No results found for usbility." Worked as designed! The other search engine returned the message "Did you mean usability?" Guess which search engine is my product of choice from here out.

Bugs are easy to find and fix. The user failed because the code failed. It's when the user fails but the code did exactly what we programmed it to do that we face usability issues. And it is precisely the fact that the code works is why it is sometimes hard to get people to fix these problems.

The solution is based in Carroll's system definition. The user context is part of the system, and all definitions of success and all test plans for the system must include this element. Error and ignorance are part of the human context and good system designs are programmed to deal with both.