RE: This too is technical communication

Subject: RE: This too is technical communication
From: Stuart Burnfield <slb -at- westnet -dot- com -dot- au>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Thu, 07 Jun 2007 12:36:56 +0800

Lauren said:
> Knowing a user still requires some process to get from not knowing
> to learning and then to knowing.

I call that process "asking questions".

> Technical writers are not born "knowing." How could it be
> possible that an interviewee would "know" the new situation?
> What is that person's learning process?

Rather than have the SME explain things in "For Dummies" mode, I usually
find it more useful for *me* to summarise what I know of the project,
and have them correct me on the parts where my understanding is wrong or
incomplete. Then I ask some questions and come out with my revised and
improved summary, get feedback, go into more detail, and so on.

So I might start an interview with a brief statement just to make sure
we're starting from a firm foundation:

"Bob, I understand that that iSink is a new range of Bluetooth-enabled
cast iron waterskis, and you're in charge of the software development?"

Bob: "Yes, though it will be Wi-Fi, because Bluetooth doesn't work over
the length of a typical tow rope." (chuckles at TW's naïveté) "And the
skis will be lead."

Stuart: "So, I read in the functional spec that iSink has three software
UIs: the console on the boat, the ski-mounted browser, and the VR goggles."

Bob: "Yes, that's right. The goggles might slip to version 2."

Stuart: "I'm just curious to know if you considered using Ethernet cable
for the tow rope to avoid the wireless networking issues."

Bob: "No, the breaking strain on an RJ45 connector is typically only..."

And so on. At the end of the interview I might do a quick final summary
("So it's Wi-Fi lead waterskis, two UIs that require online help and
possibly a third--decision on that next Friday--and a hardcopy
operations guide, presumably laminated."). I would follow up with a more
detailed written summary based on my notes, research and frantic
Googling after the meeting.

The point of all this is that, however much I might be nodding away as
the SME explains the project, I don't know if I really understand
correctly till I try to explain it back.


Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more.

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.


Previous by Author: RE: This too is technical communication
Next by Author: Re: Organizational chart
Previous by Thread: RE: This too is technical communication
Next by Thread: RE: This too is technical communication

What this post helpful? Share it with friends and colleagues:

Sponsored Ads