My company just finished editing a user interface. Officially, the contract was for an “expert usability evaluation,” but what we were doing was editing. Good user interfaces start with good architecture, but achieving real software usability requires recognizing where a user interface has gotten it wrong, then making it right. Often, successive rounds of critical appraisal, revision, and refinement are needed to remove the defects. This is editing, and editing is one of the core skills for software and applications developers. It's pretty much the same story whether you are editing a program, a book, or a user interface.
I have long been envious of writers whose fingers fly over the keyboard, producing first drafts that are already final copy. For myself, writing is a slow, sometimes frustrating, and often fitful process, the first fruits of which tend toward the indigestible. Fortunately, I am a pretty good editor. Over the years I have learned how to step back from my writing, peruse it with jaundiced eyes, and identify the problems in need of rework. An article may go through four or five rounds of heavy-handed rewrites before I am satisfied that the results are ready for prime time.
In truth, much of what I know as a writer I learned from years as an editor of books, journals, and newsletters. Do enough of this, and editing gets into the bloodstream. The editorial frame of mind becomes a way of approaching the world. For me, some habits of editing have become so ingrained as to be almost automatic and unconscious. I can be scanning a book in a store and will spot a typo as I flip the pages. It is as if misspelled words were in boldface, leaping out of the page to grab my attention.
This ability can be a somewhat embarrassing talent, especially when coupled with poor impulse control. On one occasion, I was waiting for a table in one of those trendy little French cafes with a chalkboard menu. Without hesitance or thought, I crossed over to the chalkboard and casually corrected a misspelled word. My daughters were mortified.
Some people are born with a flair for orthography. Not I. Programmer-author P. J. Plauger once remarked that he is almost constitutionally incapable of misspelling a word. This he told me in preface to a suggestion that I get someone who could spell to go over my manuscripts. Instead of taking his advice, I learned to spell.
Two things taught me. Years spent as a journal editor, trying to rescue the obscure, mangled, or awkward prose of pedants and researchers, started the process. Spell checkers finished it. I finally got spelling down pat after years of using a word processor with built-in spell checking. Spell checkers are marvelous teachers because they do not actually check or correct spelling, they just tell you if they don't recognize a word. The early checkers didn't even offer guesses. So you ended up having to grab a dictionary either to reassure yourself or to get the spelling right. In any case, you got immediate feedback and played an active role in your own learning. Now, it has become hard for me not to see spelling errors.
The story is much the same in editing user interfaces. Once you begin thinking in terms of usability, you may find it difficult not to see usability problems wherever they lurk. You start noticing the way signs in a hospital confuse or mislead visitors, how hard it is to remember which button to press on a VCR remote, or the way a neighbor's driving directions can be interpreted in multiple ways.
Of course, finding the flaws in other systems is not the hard part; the big challenge is seeing the shortcomings in our own work. For instance, that expert usability evaluation I mentioned was sandwiched into a busy travel schedule. Our report, identifying some one hundred usability defects in the client's user interface design, had been carefully proofed before being dropped off for printing and binding at one of those 24-hour copy services. On the morning of the consultation, with our client and his staff and his boss gathered around a conference table, I opened the report and instantly spotted a glaring typo on the very first page. Isn't it always the case?
Editors and writers know this effect and exploit it. If you want to proof your own writing, shove it in a drawer for a few days before rereading it. If you want to identify usability defects in your user interface, set aside the designs, sketches, and screen shots for a day or two while you work on something else. When you come back, it will be easier to look at your work from a fresh point of view and to see the problems.
Magazine editors often approach their work from the point of view of an archetypal ignorant reader. Pete Bickford, erstwhile User Interface Champion at Apple, has a similar take on assessing user interfaces. He used to say that his job involved playing the part of the dumbest user on the planet. It's a mindset in which you tune out all the things you know about computers or the application or the programming. If you can look in the upper right corner of a Windows application window and see a button to multiply something, you are on your way to becoming a more effective editor of interfaces.
Studied imperviousness and practiced innocence are not enough, however. Editing is creative as well as critical. You can't just cross things out, you have to also write things in. What you write involves judgment informed by knowledge of good form. Just as you can't be a newspaper editor without knowing the basics of journalism and the rules of grammar, you must understand the rules of usability if you are going to edit user interfaces. You need to recognize unnecessary complexity or awkward workflow, then know how to simplify messy organization or smooth out jerky operation. You even have to learn to see the things that aren't there, such as the missing feedback to the user or the functionality that isn't visible where and when it should be.
In editing interfaces, it helps to be negative, to be able to take on the attitude of the stereotypical New York theater critic or book reviewer, focusing on weaknesses and mistakes, on problems and shortcomings. This may be the easiest part for programmers and engineers, who seem almost by nature to be a critical lot. Put any two of them in front of a whiteboard and you get three strong opinions—followed by an exchange of verbal artillery. They are quick to point out the flaws in each other's designs or the limits of proposed solutions. On the other hand, their typical response to criticism, implied or proclaimed, is to explain.
A key rule for editing interfaces, then, is never to defend or explain anything. There is almost always a reason why you put that button over there or refreshed the thumbnail image when an item was clicked, but the real issues in usability are not the internal reasons but the external consequences. To stay in tune with your capacity as creative critic, you have to stop yourself from justifying or explaining your own design and programming decisions.
Just as editing can teach a lot about writing, the more you practice critical editing of user interfaces, the more you learn about good user interface architecture. If you find yourself reaching for a blue pencil when someone hands you a screen shot, go ahead. You may be on the way to a new career as an interface editor.
From Software Development, Volume 3, #11, November 1995.