Sunday, October 4, 2009

Personal Intrusions, or Hi, My name is Peter and I'll be your Technical Writer for tonight

I did a session on technical writing for a group of forensic accountants a couple of weeks ago (Williams and Partners). They were terrifically interesting people and scary good at their jobs. I had a ball and--I don't know about them--but I learned lots.

It's important that when these people present their reports to their clients (and to courts) that their reports appear to be objective: It's fatal for the organization to appear to be advocating for any of the parties involved in the dispute. We tend to do the same when presenting technical information: We tend towards the impersonal. Even when writing user manuals we tend to restrain ourselves from introducing references to ourselves (in some cases we never even talk directly to the reader using, for instance, "you").


I was thinking about this when I last worked through a set of voice mail dialogs. I remember the research that showed that people responded to positive feedback even when it came from automated sources. However, I was still surprised when the voice at the other end of the line said things like "OK", or "That's great". I was also surprised that I responded positively to the feedback. The script for the automaton at the end of the telephone line was written to be surprisingly personal and, guess what!, I responded personally.

In some cases, when writing technically, a personal touch would work against the author's purpose. Back when I wrote whitepapers for Microsoft there were very definite rules in the style guide that ensured that the papers came across as impersonal and objective (as opposed to many of the technical/programming pieces I wrote for Microsoft where we often used a "geek-to-geek" style). Whenever the author's purpose to impress the reader with the feeling that the information is beyond reproach, an impersonal style works well.

On the other hand, that style would be inappropriate in (for instance) a blog. Here (and in my column for Visual Studio Magazine) one of the purposes is to build up a personal relationship, to establish a rapport with the reader, to let the reader see the personality behind the information.

In user manuals we want to get the reader "on board"--we want the reader to drink the Kool Aid. So why don't we personalize those manuals more? Why don't we make it clear (even if it isn't true) the manual is written by a particular person who is keenly interested in helping the reader out? I recognize that many manuals are written by committee so this person would be (as in the case of that automated voice at the end of the line) a "polite fiction"*, but it seems to me that I would better meet the purposes of the document.

(I'd love to claim that this is all original thinking but I suspect that I'm repeating much of what I took away from Untechnical Writing - How to Write About Technical Subjects and Products So Anyone Can Understand and
by Michael Bremer--the author of the highly-acclaimed Sim City manuals).

Reading or read

* a lie 

No comments: