To Operate Shower DO NOT PULL HANDLE

I went and got a massage last week. After being relieved of a great deal of muscle tension and no small sum of money, I returned to the spa’s locker room to take a shower. On the wall of the shower stall was hung a sign, about a foot square, printed with large block letters: “To operate shower DO NOT PULL HANDLE turn handle sideways.” I followed the instructions and was rewarded with a refreshing stream of hot water.

The shower handle was a little loose on its bearings. Clearly the establishment has suffered repeated instances of unintended property damage when their customers yanked in frustration on a handle that was designed to be turned, not pulled. But here’s the thing: the handle looks like it was meant to be pulled. It’s a flattened oval extending forward from a central knob. It looks like one of those kitchen sink faucets that you lift up to turn on.

Doubtless printing the sign was cheaper than replacing the shower fixture, so the owners of the spa went with the sign. But consider the same circumstances applied to software. How often are people told “just don’t do that,” or “it’s not designed to work that way”? It’s probably not that much cheaper to “educate” a generation of users than to fix the software to work the way the users expect. Of course, for the untold legions of tech support staff stuck supporting closed-source software, fixing the problem is not an option. But for anything open-source or developed in-house, it potentially is.

So here’s an idea for a software development model. I just made this up; maybe companies already do it. Have a user and a designer sit down together. Let them play with bits of paper — yes, paper — on which are printed mock-ups of each screen in the software being developed. User “clicks” on something, designer shows the result and asks if it’s what the user expected. Pages can be copied, ripped apart, and taped back together as necessary. If something is missing, the designer sketches it right there and adds it to the pile. Videotape this whole process, and give the videotape to the developers, who then write an application that does exactly what the user wants. Repeat for each update or new feature.

No mock-up or screen shot or demo is sufficient if you can’t interact with it. You need to find out what people think Button X will do, as opposed to what it “should” do. If someone’s using software the wrong way, maybe it should be designed differently.

Personal experience: At one job I had, after the web content-management system got upgraded with cool JavaScript rich-text editing widgets, they discovered that what everyone really wanted to do was cut and paste from Microsoft Word. Of course, Word’s funky HTML screwed up the cool widget. “Don’t paste from Word,” they said. Ours’ not to reason why…