Three Unforgivable Usability Sins

Awful as they are, these application design errors — all the fault of lazy developers — are entirely too common.

I lived in Buckminster Fuller’s summer house for a year, not long after the brilliant old man died. His grandkids hadn’t really cleaned it out; the furnished house (built in 1762 as a Captain’s House overlookiing the Penobscot Bay) still had his personal library, a spare pair of eyeglasses, boxes with gifts received as a visiting dignitary (such as a rikshaw in the root cellar). I learned to love Bucky, and not leastways because of his inventions and writing.

Among the tiny watts of enlightenment Buckminster Fuller shared was the wonderful concept of dymaxion, a holistic view of energy use. It’s generally defined as “world-energy efficient,” or “that odd three-wheeled car Buckminster Fuller designed in the ’30s or ’40s,” but in fact the term encompasses much more. One example that I remember is the notion of a bank “saving money” by hiring fewer tellers despite a brisk lunchtime business. Bucky pointed out that hours of human creativity and production (most of which would be invested in that bank) were wasted by customers stuck in line. So the bank was wasting energy in the name of saving it. (I was so impressed that when a kitten acquired us that year, we named him Dymaxion; that was a huge mistake, as cats don’t care about being energy-efficient. And Max was as dumb as a box of rocks.)

Bucky’s philosophy had a big impact on me. Ever since, I am particularly irked when I see someone take a “shortcut” that saves that individual a couple of minutes, but thereafter causes extra effort from every single user. Nowhere is that more obvious than in these all-too-common errors in software design (non-)usability.

Making the User Do Something the Computer’s Better At

It’s happened at least a half-dozen times in the last week. I go to join an online community, or I make an online purchase, or I login to a financial site. I’m asked to type in my SSN, or my phone number, or a credit card number. But the site doesn’t accept my input if my SSN has dashes, if the phone number includes parentheses, if the credit card number has spaces. Why? Why? Typing in one long string of numbers, sans spaces, is error-prone for any user and even harder to read back; why make him try? When the computer is far better at tasks like this?

It’s because a developer got lazy. The algorithms to strip out formatting codes have been around since the days when COBOL dominated the earth. All it takes for a program to evaluate a credit card data entry field is to strip out anything that isn’t numeric digits, make sure it has the proper number of characters, and… well, that’s all there is to it. This is only a few lines of code.

Sure, developers don’t want to write any more code than they have to, because it has to be debugged, tested and supported. Yet, like the people queued up in Bucky’s bank example, the programming team’s momentary time-savings has a long-term cost in user time and frustration.

Losing Context

This one is a little harder to explain, because by definition it’s about optimizing a user task that has several steps.

Let’s say that you’re cleaning out or organizing a database. It doesn’t matter what: it could be a list of the hundreds of books in inventory, or blog comments, or a to-do list shared by a collaborative team, whatever. It’s long, so the data is presented in several sections.You scroll through pages of item lists, and select one item for particular attention. Click on that item (say, to mark the blog entry as spam), fiddle with it as appropriate, choose “Save changes,” and — the system goes back to page one. It doesn’t return to the page you were looking at, from which you chose the last item.

To mess with any other items in that list, you have to repeat the entire process. That’s a major annoyance when you were just editing stuff on page 19!

It’s a small thing to fix for the developer, and yes it requires a little bit of bookkeeping. The computer has to save the current presentation state and return to it after the edit process is complete. It could be messy if the record was deleted and the list needs to be updated.

But how much time does it require to do it right, compared to the hours it wastes for me — and for every other user who uses your system?

I wish this were a rare occurrence. But I bet you can recall an example of a similar system that you’ve used in the past few weeks.

“Blaming” Error Messages

Poor software is often arrogant. If an exception occurs, the code dutifully ticks off the problems that it knows how to solve (“let’s see, was it a problem with this? no? how about that? no?”). If it reaches the end of the list of predetermined problems, then, by golly, the reason that the task didn’t succeed must be the fault of someone else! It can’t be a problem here, oh no—

—Not that I can get worked up over this, or anything.

Usability experts have slowly drummed it into the heads of novice programmers that error messages shouldn’t blame the end user. That’s the optimistic observation. I can still find software that says, “You entered the wrong information” (even if I didn’t) but most error handling does, at least, give some vague suggestion about how to handle the situation.

On the other hand, applications that throw up their hands and admit defeat are still too willing to assume the error is something beyond its control and shunts the problem-solving effort to an innocent bystander. These programs don’t blame the user; instead, the error messages blame another part of the system with which the application is intended to connect: “You have a problem with your network connection. Contact your administrator” Or “The site isn’t responding” (and thus it’s all their fault, not mine).

This abdication of responsibility places an unnecessary burden on said innocent bystander (presumably an already-overworked IT professional) and creates bad feelings based on inaccurate assumptions (i.e. the program said it was your fault so why haven’t you fixed it?).

Microsoft Outlook is the easy example here; if the mail server is unreachable (because, say, the user pulled a plug out of the wall) the error message instructs the user to whine at the e-mail administrator and whimper about the IT department’s poor service. Okay, maybe not in so many words, but that’s the usual result. I’ve encountered people who go three days without e-mail (hard as that may be for me to fathom) because they’re waiting (patiently but with increased annoyance) for their mail admin to fix a problem… when the problem is on the local workstation. “What lousy service!” thinks the user, when the situation is caused entirely by poor usability design.

Instead of saying that the network connection isn’t broken or that the destination server is offline, how ’bout saying that this computer couldn’t reach the server? Why add more stress to the relationship between IT and the user community? How could you not think this is a problem?

These three unforgivable sins would soon be addressed if every developer were required to (a) spend two weeks as a user of the software she writes and (b) spend two weeks on the help desk supporting her application.

But perhaps my list is incomplete. Are there other “lazy programmer tricks” I’ve missed?