The User is Always Right

Sometimes, we software developers get a little arrogant. I believe everyone designs their software to be as easy-to-use as possible, but we don't always hit the mark. And when users gets themselves into trouble because of something they did, our first reaction is to blame them:

• "It's covered in the help file; didn't you read it?"
• "Don't click that button unless you know what you're doing."
• "Why did you do that?"

I found myself guilty of this recently. In Stonefield Query, you start a new project by clicking the New Project button in the toolbar and selecting the directory where the project files should go. The project files are specified in a file named SFQuery.INI, which is created after you click OK in the File dialog. Works great.



Well, almost. One developer reported an error in this process. It turns out that not only did he select the desired folder, he also changed the name of the file to something like MyProject.INI. Of course, the application is looking for SFQuery.INI, doesn't find it, and gives a warning message. My reaction (not stated to the developer; I'm not that rude) was why did he expect that to work. I wouldn't change the name of a Microsoft Word DLL and then be surprised when it stopped working.

However, we added some text to our help file documenting that the file name can't be changed so no one else would run into this. That's when we ran into Doug's Axiom of Software Development #1:

Axiom #1: People don't read.

Another developer ran into the same problem. Were these guys roommates in college? When we pointed out that this was documented, he replied that he hadn't read the documentation. Why should he -- how complex is it to click on the New button, pick a folder, and click OK?

So, we "fixed" the problem by ignoring the filename entered by the user and just used the path when we created SFQuery.INI. That's the end of that issue.

We get a call from a developer, during which Doug's Axiom #2 appeared:

Axiom #2: People aren't very good at communicating.

He said the New function wasn't working. I love that level of detail. Let's see, "not working". Does that mean you get an error message? Have to use Windows Task Manager to terminate an endless loop? The monitor shatters, flinging shards of glass into your face? Nope, it just didn't create the project. When we pursued this further, it turned out that he had typed a new filename (the infamous MyProject.INI) but when he checked the directory, no such file existed, just some other file named SFQuery.INI.

Then the light bulb came on. This wasn't the user's fault; it was mine. Why, when we wanted the user to select a directory, did we display a file dialog? The reason was that we wanted the user to see if a Stonefield Query project already existed in that directory or not; if they saw SFQuery.INI in the list of files, they'd know it did. That's not a good reason, however, so we finally did the right thing: we changed the dialog to a Get Directory dialog. Now there's no confusion about what the user needs to do.



A second example: a user complained some of his reports were missing. After some detective work, it turns out he'd deleted them by accident: he meant to edit the report but clicked the delete button by mistake. But how could it be an accident: we prompt the user with the typical "are you sure" dialog, so he must've clicked Yes to confirm the deletion. Ah, but we forgot Axiom #1. The problem is that Windows has so trained users to simply click Yes without reading the message whenever a dialog appears that it's now second-nature. There are a few possible solutions to this:

• Reword the prompt so Yes means don't delete the file. Probably not the best choice.
• Provide an undo function so the user can recover the deleted report. We'll likely do this, but that only works if the user immediately realizes what they've done. It wouldn't have helped this user.
• Make the delete function harder to select. Right now, the delete button is right beside the edit button. In hindsight, this is clearly a disaster waiting to happen. Maybe it shouldn't be in a toolbar, only a menu, since report deletion is pretty rare compared to creation or editing.

The conclusion: I need to spend more time thinking about things from the inexperienced user's perspective. And remember Axiom #3:

Axiom #3: The user is always right.

Not necessarily in how they communicate their ideas (see Axiom #2) but at least in their intent.

For other ideas along these lines, see http://www.codinghorror.com/blog/archives/000550.html.