
|
December, 2005 |
In Defense of the Typo
My boss called me into his office last week. One of my subject matter experts (SMEs) had complained that my draft documents sported the odd typo. My boss, being relatively fair and keenly aware that he knows nothing about technical writing, wondered how weighty such a matter is: Shouldn't writers take offense at even one typo?
My response was simple: That depends. In a draft document sent out for technical review, no. In a finished publication, probably.
My boss listened. He agreed with me that I needed to educate my SME about the review process: My SME didn't know that technical reviews address content; editorial reviews (which SMEs don't do anyway) address minutiae, like typos.
I left my boss' office annoyed but much more aware of how clueless most people are about the writing process (which, incidentally, was the topic for last June's humor column).
Nonetheless, I started thinking about the typo. How serious an offense is a typo in a document, even a published document? If the document appeals to the user, and if the information within is accurate, complete, and logically organized, is a typo that big a deal?
I'm not talking about typos that spell-checkers should catch, like taht instead of that. I'm talking about the typos that writers who've spent a month with a document, who know its headers and footers and headings and footnotes like they know their families, miss simply because they're too familiar with the material.
One Friday, I spent the entire morning proofreading a 20-page document. I read each word backward and forward. I checked the title page, copyright material, headings, text, tables, procedures, and footnotes. I made sure the images reflected exactly what the surrounding text promised.
By lunchtime, I hated the thing. Convinced that I had done an excellent job, however, I PDF'd the beast and sent it to my reviewers as "Release Candidate 1." I also forwarded it to another writer. She wrote back, "Great job! There's one typo "
I'd typed "Office or Foreign Assets Control" when I'd meant "Office of Foreign Assets Control." It was on the bottom of the first page, and I'd missed it.
Given that this happened post-typo-conversation with the boss, I crumpled with mortification. Then I fixed the typo and redistributed the document, which won rave reviews from my SME. But I thought about that typo all weekend.
It's hard to explain to people who know nothing about writing what really matters in a document. As for bad technical writing, the world is rife with examples. But about good writing? Does a typo make a good document bad?
The answer I gave my boss in our meeting holds up: That depends.
Consider this: A typo on a résumé is bad. A typo on a writer's résumé is very bad. A typo in a published user's guide? Bad. A typo in a user's guide for a product whose specs changed up to the last minute and whose management provided three days to write the user's guide? Well, the users are lucky there is a user's guide.
Typos are less a reflection on quality, in my opinion, than they are of circumstances. CNN.com's pages bleed with them. Somebody out there is putting up content in a hurry. But it's a news site, so who cares? I'd rather read an imperfect article about the London bombings as soon as they happen than read one that's free of typos but published two days later.
If a document tells me what I need to know, I'm inclined to forgive the typo.
To appease my SME, I promised my boss I'd do a quick read-through on
my drafts before I sent them out for review-in addition to the spell-check
I already do at this stage. I also asked him not to expect a document
completely free of flaws at any stage. When my boss hired me, my résumé
had no typos. But it didn't say I was perfect, either.
This article originally appeared in the September 2005 issue of The San Diego Signature, the newsletter of the STC-San Diego Chapter.
|
|||
|
How to Get Book Reviews Published in Technical Communication |
||||
|
To be removed from this distribution list, please send us an e-mail with the word UNSUBSCRIBE in the subject line.
|
||||