TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> Our first step in doing this is to get into our customers (actually
> our users) minds. Ideally, we would like to visit our clients, interview
> them, and observe their usage of our documentation; however, do to
> budgetary constraints, this is not an answer. So . . . we have decided to
> come up with an incredible survey/questionnaire for our clients to relay
> their documentation wants, needs, requests, and opinions.
"Observe their usage of the documentation?" Oh, just what I want. A technical
writer hanging around my office while I am trying to work. <shiver>
Ahhh, surveys. Another tool of the work-shirking tech writer.
I hate to say this gang, but it is inhumanly impossible to get a clue of what
users want with a survey. 999 out of 1000 surveys are a waste of time and
provide only a minute amount of insight.
First, surveys are rarely if ever scientific. The only people who answer
surveys are the bored or opinionated. These are not the best people to define
what goes into a document.
Second, no survey can possible address all the nuances of doing a job. There
are countless little issues and gotchas that never get into a survey or get
And most importantly, surveys just defer the inevitable. At some point you have
to learn about the topic and what users do. If you're really serious about
"getting into your customer/user's head" then do their job for a while.
When I wanted to know how to install and setup stored procedures in a client's
Oracle database - I learned how to do it. It was a breeze documenting it once
I knew how to do it. I knew *exactly* what the users would need to know
because I was a user for a while. I also understood all the little
idosyncracies of doing it, particularly what to warn the user and how to
communicate complex steps.
Sitting around your cube and masticating over what to put in a survey may feel
intellectual and very proactive. But it is ultimately just a mechanism to avoid
the real work of learning how to do things.
And as we all know: it is impossible to write a meaningful document without an
intimate understanding of the topic/subject matter.
Now are we all interested in my little scheme of marching up and down the
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/