User or Usability? (or, The Psychology of Software Support)

Before going into Software Engineering, I took a job in PC support at the university from which I graduated where it was my job to answer the support questions of the professors and administrative staff. I quickly realized that my job had very little to do with any sort of proficiency with technology as it did with simply being a sink for raw human emotion.

A veritable “who’s who” of the emotions involved in grief, I’ve seen a professor indignant and rage filled over the news that a crashed computer and unsaved document added up to hours of lost effort.

I’ve tried to console a staffer in tears over the embarrassment and despair of her 10th support call over Excel, whimpering, “I just don’t get it. I’m just no good at this!”

I’ve witnessed the bewilderment and denial of a PhD at the words of his document all running together: “I don’t understand, I’m pressing the “shift” key to shift the cursor over”.

My heart goes out to these people — technology is harsh and unforgiving (although in fairness, the “technology” of the space bar has been around at least since mechanical typewriters).

I would imagine that most users spend a not insignificant percentage of their time on a computer in some sort of troubleshooting mode. I actually enjoy working with computers, so my patience threshold for futzing around with something I don’t understand is probably higher than average — but woe to the user who actually doesn’t want to sink hours of time into learning how to use a new program.

It’s easy to point to the end user as the one at fault, but I think this is a mistake. I think more often than not, it’s a usability problem, not a user problem.

Usability is a fragile thing. We like to label programs as “intuitive”, but they are only that way because we’ve been trained on what to expect from previous programs. So when we say that a program is intuitive, we really mean that it conforms to our expectations — expectations that have been formed by the evolution of programs which have come before. But when a program behaves in an unexpected way, our confidence in its use is rattled, and we become adrift in its apparent arbitrariness. What was intuitive for its designers turned out to not be so for its users.

Usability Expert Jef Raskin warns against the flippant use of “intuitive” to describe interfaces:

“The impression that the phrase “this interface feature is intuitive” leaves is that the interface works the way the user does, that normal human “intuition” suffices to use it, that neither training nor rational thought is necessary, and that it will feel “natural.” We are said to “intuit” a concept when we seem to suddenly understand it without any apparent effort or previous exposure to the idea. In common parlance, intuition has the additional flavor of a nearly supernatural ability humans possess in varying degrees. Given these connotations, it is as uncomfortable a term in formal HCI studies as it is a common one in non-technical publications and in informal conversation about interfaces.”

He goes on to note that we should more accurately favor the word “familiar” over “intuitive”.

So really, when users are at the mercy of support it’s not because they lack intuition, a word that is connotatively linked to intelligence — it’s that they lack familiarity.

The person questioning her own self-worth over Excel may be in the wrong profession — or perhaps Excel is not all that intuitive. Excel in particular is an extremely powerful, and complicated program, one that, for some reason, is present on most machines in corporate America. Given its ubiquity and unusually broad user base, it needs to pay particularly close attention to usability.

One way a program can make up for being complex is by encouraging the user to explore and try out features knowing that they can always back them out with “undo”. In my experience Excel is particularly bad at this, not because it implements “undo/redo” poorly, but because it is such a complex and bloated program that it needs to go above and beyond conventional “undo” semantics.

I’m continually surprised, when after futzing with charts (or whatever), making changes and having “undo” disabled: “Can’t undo”. Can’t undo? Why not? I just modified the state of the document — back out my changes, Excel! Don’t make me Revert To Saved!

Now that I find myself on the other side of the curtain of application development, I try to be mindful of the user on the other end. When I watch people use an application I’ve written and they struggle with how to do something, my gut reaction is that it’s a training issue.

But it’s not. Ever. It’s a Usability Fail, and it means that I need to listen to the users, and try again.