Usability in everyday things

The power went out last night. Several times. In what should have been a fortunate stroke of luck, the outages began at 11:00pm, so I should have been able to just go to sleep and slumber the problem away in ignorance.

Instead, I had a couple of opportunities to observe some usability that wasn't too usable. Keep reading to see how we can learn some design lessons just by looking around.
The first design lesson was courtesy of our Electric Company. As soon as the power went out, my wife felt compelled to call them up and let them know that we were without power. I didn't have the heart to tell her that when the entire west side of town drops off the grid, it's gonna make a noise somewhere. She felt some satisfaction in calling to report the outage because she was Doing Something about the problem.

Lesson One:   Users want to feel in-control, even if they're not. They're driving - not the computer. If you're one of those people (like me) who can't stand riding in a car -- you've got to be driving -- then you understand this idea. Make sure your users feel that they're controlling the experience.

Ok, so my wife's on the phone with the Electric Company, and I can hear them gathering information. Name, address, address again (spelled), address again (spelled as it appears on our bill from them), name again... My wife glowered accusingly at me when I started laughing. It occurred to me that they might be trying to guard against someone fraudulently reporting a power outage , but I think the real issue was that they had a rigid process that wasn't able to absorb unexpected conditions. It would have been a whole lot more efficient to break protocol and get to the point: "Yeah, west side? Right - we've got it. Thanks for your help." Click. Meanwhile, the management center is lit up like a Christmas tree showing faults all over town and they're validating billing information.

Lesson Two:  Expect the unexpected. Sorry, that's a cliche, but it's true. S**t is gonna happen. Design enough flexibility into the system so that the people who are running it can apply their infinite capacity for adaptability and deal with the problem. Do Not become part of the problem.

The lights are out now, and the thunder rumbles soothingly into the distance. BEEEEEEEEP. There's a candle on the nightstand beside our bed, and the cats are settling into their normal spots. BEEEEEEEEP. I lean over and kiss my wife, and think that this might not be all that big an inconvenience. BEEEEEEEEP.


Culprit #1 - the UPS on my wife's computer. Easily dismissed by shutting off the load. Culprit #2 - our alarm system. This one stymies me for a bit, but the Cancel button seems to do the trick.

An hour later, the power came back on. Lights come on, fans whir to life. I wake up and start turning off the lights, and then the power goes off again.


Stomp, stomp, stomp. . %^%#@*&!##@. Stomp, stomp, stomp.

This happens three more times during the night. Each time, the cursed alarm system screeches at me, proclaiming that it alone has a reserve of power -- enough, in fact, for it to squander its power by piercing the midnight silence. Thank God the alarm system told me I had no power, because that little fact might very well have escaped me otherwise.

Lesson Three:  Forcing users to acknowledge your "help" is a perilous move - use it sparingly. Consider "Clippy" the paper clip. A good portion of peoples' animosity toward the clip is not the fact that it's smugly offering advice, but that it doesn't know when to leave you alone. When you offer feedback to your users, endeavor to do so without requiring the user to stop what they're doing, deal with your interruption, and then try to figure out what they were doing before you butted in.

It's morning again. Lights are on, and everything's back to normal. And I'm tired.