Dead Ink Vinyl

I have an interest in human-computer interactions, or software user interface development. I am not a usability engineer, but I acknowledge that most business software has significant usability issues. In fact, I have been responsible for my share of those systems.

The issue of usability first captured my attention seriously in 1999. I volunteered my free time at a convention and was directed to the support desk. The staff there gave me a quick rundown of my responsibilities and placed me in front of a computer. I was charged with performing three simple types of transactions for the conventioneers, but I quickly found that the software was not setup to make those tasks easy. After a couple of operations, it became clear that the system was a simple CRUD for the database, which was not at all convenient because it meant that about five screens were involved for each of my transactions. As I mulled over ill thoughts about the obvious inferiority of the software developers responsible for this application, I slowly came to recognize that, actually, I would have developed the interface in the same manner: designed around the database instead of around the user’s common tasks. My software was probably just as unfriendly to its users as this convention software was to me.

I think that there are a lot of factors that contribute to poor ease of use in software, and most have been enumerated elsewhere. Much of the literature I have read seems to assume that developers have a plethora of time and resources on their projects, which leads to conclusions that software developers intentionally develop software that is hard to use. Thus, conventional reasoning enters the realm of conspiracy theory and developers are pasted with euphemisms for willful ignorance or outright malign contempt of their users.

However, most business application developers I know derive supreme satisfaction from delivering software that pleases its users. Instead of ignorance or malignity of the software developers, the real hurdle for software usability is time. On a tight schedule and a tight budget, who has time to design for usability? Software development contracts — even those with Fortune 500 companies — rarely have an empirically-defined usability clause, so there exists a very real disincentive to expend limited resources on ease of use. There is no checkbox on a list for it — nobody can withhold payment because of its absence — so it would just cut into the profit margins to seriously address it. Of course, long-term, it probably cuts into repeat business to not build software with which users enjoy interacting, but who’s counting?

Anyway, one of the authorities in the field of software usability is Alan Cooper. He has written two highly-praised books on the topic: The Inmates Are Running the Asylum and About Face 2.0. I picked up both of them a while back and have been slowly chugging through Inmates as a “background process”.

Admittedly, Cooper had me hook, line, and sinker — for a while. Then he gets into his discussion about software apologists and survivors. Apologists are power-users and survivors are everyone else who uses computers. Cooper then goes off the deep end and says two incredibly stupid things.

It [computer literacy] creates a demarcation line between the haves and the have-nots in society. If you must master a computer in order to succeed in America’s job market, beyond a burger-flipper’s career, then the difficulty of mastering interactive systems forces many people into menial jobs rather than allowing them to matriculate into more productive, respected, and better-paying jobs.

Well, that is not so much stupid as it is a duh. Let us play Mad-Libs to better expose Cooper’s reasoning, dropping it in a context from the early 1900′s:

The ability to read creates a demarcation line the haves and have-nots in society. If you must master basic literacy to succeed in America’s job market, beyond a burger-flipper’s career, then the difficulty of mastering letters, words, and sentences forces many people into menial jobs rather than allowing them to matriculate into more productive, respected, and better-paying jobs.

So what? Of course any evolution of the job market causes pain as new skills are required for existing jobs. However, for all the new skills that need to be learned, frequently old skills are no longer required, so the overall base of knowledge necessary to perform a task remains about constant or decreases over time. Only a luddite seriously bemoans this natural evolution.

An acquaintance of mine told me about his work as a surveyor thirty years ago. You had to tediously measure elevation, write down the distances and angles, you had to know how to layout the numbers, perform the trigonometry, and analyze the results. Now, it is almost all automated by computer: GPS and lasers make elevation, distances, and angles near-trivial, the measurements are stored on disk as they are gathered, the are then dropped in a computer which does all the math and generates the raw analysis. So in exchange for “computer literacy”, the surveyor no longer needs to know trigonometry or how to work the information “by hand”.

To highlight this point, let us move on to the second inane comment by Cooper, just a paragraph later:

An accountant, for example, who is trained in the general principles of accounting, shouldn’t have to be computer literate to use a computer in her accounting practice. Her domain knowledge should be enough to see her through.

Let’s play Mad-Lib again, this time placing using the context of the mid-1900′s:

An engineer, for example, who is trained in the general principles of engineering, shouldn’t have to be slide-rule literate to use a slide-rule in her engineering practice. Her domain knowledge should be enough to see her through.

The usage of a slide-rule is really non-obvious, even to a person possessing domain knowledge in engineering — and yet the slide-rule was an incredibly useful tool to engineers. We could have gotten to the moon using pencils, paper, and long division, but slide-rules and look-up tables got the math done a lot faster. Cooper seems to entirely miss the complementary relationship between domain knowledge and tool proficiency. And he seems to forget that all tools — from the abacus to the slide-rule to MATLAB — require specialized knowledge that lies outside of domain knowledge, but within the realm of professional expertise.

Tools offer the exchange of training for efficiency: by learning the tools, a person can apply the tools to get more accomplished.

This does not mean that software should be harder than necessary to use, or that I am apologizing for the generally sorry state of contemporary software usability, but rather that Alan Cooper’s Inmates is based on a deeply flawed view of the relationship between software and its users.