by Patrick O'Hannigan

How to think about technical writing (Concentric Circle #1)

Technical writing, neatly defined by Lisa Posner as "the adaptation of information in a plain style for a particular audience," is essentially populist. By that I mean that even when saddled with fashionably awkward labels like "design communicator" and "information engineer," technical writing affirms the intelligence of non-specialists while working to meet their need for increased efficiency through easy access to relevant information.

This way of thinking about technical writing, though not original, may come as news to anyone who writes advertising copy. Advertising, after all, has a long tradition of analyzing and then shaping or catering to public tastes. But the line between advertising and technical writing follows the river dividing wants from needs, and that in turn implies that a populist outlook is useful to the ad writer but mandatory for the technical writer. Accurate audience assessment makes for more effective "spin" in distinguishing one widget from another, but every ka-ching of the cash register represents a handoff from marketing to technical writing, where demographic knowledge is used to assist customers rather than to attract or persuade them.

From that insight, it follows that technical writing can’t help but emphasize usability (hence the push among technical writers for "task-centered documentation" and the preference for explaining product functions rather than features). Sadly, improved usability, technical writing’s Holy Grail and Prime Directive, is frequently obscured by conformity to corporate style, congruence with product strategy, or capitulation to office politics.

By becoming what software designer and usability expert Alan Cooper calls "apologists for technology," many technical writers unwittingly display symptoms of "Stockholm Syndrome," the psychological condition first recognized in 1973, when hostages held captive for more than five days survived the ordeal by sympathizing strongly with the bank robbers who captured them. Widespread acceptance of customer focus as an operating principle in business has not yet made the ideal relationship between technical writers and end-users, or the risk of "Stockholm Syndrome" in technical writers, self-evident.

Technical writers whose work is aimed at experts can lose sight of the fact that a programmer consulting a reference guide becomes by virtue of having to look something up an honorary member of the untutored rabble for as long as the lookup takes. Does that sound harsh? It’s no harsher than Wall Street Journal technology columnist Walter Mossberg’s self-description: "I’m an enemy of what I call ‘computer theology,’" he says. "There’s a class conflict out there. There’s a techno-elite that lives in a different world."

Alan Cooper’s distinction between "homo sapiens" and "homo logicus" springs from the same insight into class differences, as does his insistence on designing for well-defined "personas," or hypothetical archetypes of actual users, rather than broadly-conceived customer groups or figments of a manager’s imagination.

If Mossberg and Cooper are right, then in some ways, artificial intelligence is not the Next Big Thing; it’s what software developers use every day—not because developers are silicon-based, but because their tools are. An important corollary to the existence of a "techno-priesthood" that emulates the logic of its work products is that anyone interpreting software designs for the general public must tread carefully, because any writers’ quest for respect from people closer to the center of programming culture will never live down its origins in the ghetto between the quixotic and the self-defeating.

(Re)locating the digital divide (Concentric Circle #2)

Mossberg and Cooper do their homework in usability as in everything else, but few politicians are as conscientious as those two men, and most pay lip service to concepts like the democratization of technology by using the hammer of public policy to smite taxpayers on the anvil of the "digital divide." Differences between "techno-priests" or "homo logicus" and the rest of us tend to be blurred rather than clarified by arguments over that divide, usually defined as "the gap between those who can effectively use new information and communication tools such as the Internet, and those who cannot."

Hobbled by ideology or lack of computing experience, politicians are easy marks for partisan studies like "Falling through the Net," a 1999 report from a Commerce Department subsidiary called the National Telecommunications and Information Administration. In that study, researchers whooped over the fact that "Urban households earning incomes over $75,000 are over twenty times more likely to have home Internet access than rural households at the lowest income levels."

Faced with an apparently urgent disparity like that, and not able or willing to make the common-sense deduction that middle-income urbanites would by definition have more Internet access (not to mention better cellular phone service) than poor rural people, politicians tend to assume that computers are charms with which to ward off poverty.

Contrary to myths spawned by that assumption and lobbyists hell-bent on wiring every school in the country for the Internet even if students in some schools can’t read, the gap that matters is not between people who have home computers and people who don’t.

People invest in increasingly affordable technologies when they can, and hope for upward mobility lives even without government help. Consequently, the gap that matters—the true ‘digital divide’ -- is the chasm between software developers and software users.

Technical writing has nothing to do with the ever-shifting gap between ‘haves’ and ‘have nots,’ but everything to do with the more problematic gulf between software makers and software users. Cooper explains this divide as a consequence of "cognitive friction," defined as "the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem permutes." Needless to say, using computer software ranks high on the list of tasks that generate cognitive friction. As a result, a technical writer who assimilates programming culture will converse more easily with his or her programmer colleagues, but if this acculturation is unconscious, it comes at the expense of the software-buying horde on the other side of the moat.

Outside the castle of the techno-priests, millions of customers turn to books, magazines, and Web sites for help with software products that rarely do what they’re supposed to without insulting the intelligence of the people who use them. Soon enough these customers become expert users, only to find that the error messages and design limitations they bumped into as novices were cousins to even more intractable problems.

Technical writers who address these difficulties from a software developer’s point of view only aggravate them. To disdain quick reference cards in favor of documentation by the pound, chop data into separate morsels for different audiences, avoid placing operations in context, or assume that non-specialists need to be shielded from jargon at any cost is to condescend to customers.

On policing ourselves (Concentric Circle #3)

Usability can be shortchanged even by those of us who know better. Anyone familiar with Intercom, the monthly magazine of the Society for Technical Communication, knows its fondness for conversations about what technical writing really is. Discussions like these can be healthy. More often than not, however, every reconsideration brings a more expansive definition of our profession to the table.

In striving to award technical writing the respect it deserves, some Intercom contributors emphasize the overlap between technical writing and professions like journalism, teaching and linguistics. Other contributors look backward, hoping to find evidence of technical writing in prehistoric cave paintings. These self-aggrandizing strategies are understandable but unpersuasive. Worse, they distract us from our mission. We do not chronicle current events, educate in broad subject areas, or wrestle with the intricacies of language as a whole. Instead, we explain technology to people who use it. All else is —or should be—incidental. We’re specialists rather than generalists, though technology is such a big part of modern life that we sometimes forget that.

By idolizing subject matter experts or basking in the glow of their achievements, technical writers lend undeserved credibility to the idea that fabulous software products are underappreciated by cretins, and that attitude becomes an obstacle to improving product usability. What our profession needs, in all seriousness, is an attitude adjustment. Much of my argument here is an appeal to the virtue of humility. I make this appeal because humility fuels the customer service that every business needs to survive, and because customer service in technical writing is most perfectly realized as an unrelenting commitment to usability.

Apart from that commitment, technical writers are just pebbles in the so-called New Economy, but with it we take flight and create ripples felt on the far shores of the world. By abandoning the fetish for irreducible complexity, the temptation to make more of computing than it warrants, the mannerisms of software engineers, and the quest for a more inclusive job title, we can make ourselves indispensable to the one group of people who really matters: our customers.