Re: Just do it (Long & Occasionally Sarcastic)

Subject: Re: Just do it (Long & Occasionally Sarcastic)
From: Tom Murrell <trmurrell -at- yahoo -dot- com>
To: TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 6 Sep 2000 05:32:33 -0700 (PDT)

--- Andrew Plato <intrepid_es -at- yahoo -dot- com> wrote:
> > 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>

<sarcasm>I don't suppose there is some other meaning to the phrase
"observe their usage of the documentation" that would occur to a
reasonable mind, is there?</sarcasm>

> Ahhh, surveys. Another tool of the work-shirking tech writer.

Nothing like being non-judgmental, is there. While I will concede that
there are "work-shirking tech writers" and some of them would spend
their time designing surveys to avoid the work they're supposed to be
doing, frankly dismissing something you don't understand is not a
logical argument. It's not even a useful argument. But that's nothing
new, is it?

> 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, how does "inhumanly impossible" differ from, say, humanly
impossible? I suspect that a logical analysis would suggest that if a
thing is inhumanly impossible that it might actually be humanly
possible. Second, "999 out of 1000 surveys are a waste of time" is an
opinion speciouly stated as if it were an empirical fact.

> 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.

Do you have any DATA to support your statement that "surveys are rarely
if ever scientific?" (Oh, that's right; you only need to deal in
opinion--yours--not facts. But you make such lovely arguments; too bad
they are based on nothing but hot air.)

"The only people who answer surveys are the bored or opinionated." Now
we know what you do all day. No wonder you're so grumpy. As for the
people who answer surveys not being the best people to define what goes
into a document, well I, too, am a "highly opinionated" though not
bored person, and I find myself an excellent judge of what should go
into a document, both as a writer and as a user of both documentation
and that which they document.

So far, your argument against surveys is (a) that they're stupid, and
(b) that they only people that take them are unqualified to have an
opinion on the subject of the survey, which is proved by (a), which is
in turn proved by (b). You wouldn't happen to have ANYTHING other than
opinion to back up any of these assertions, would you?

> 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 considered.

I read this as saying that it can't possibly be done right, so why
bother? I'm reminded of a saying: "The cowards never started and the
weaklings died on the way." (I first read it in a book by Robert
Heinlein, but I don't know if he originated the saying; I suspect he
did not.) Just because useful surveys are difficult to do is no reason
not to do them. What should be done is that some rigor should be
applied to the creation of a survey. At a minimum, the same standards
that apply to creating any other document should apply to standards.
What is the purpose? Who is the audience? What do I need to put into
the survey that will allow me to achieve my purpose with my audience?
Yep, that's hard work, but anything worthwhile is going to be hard
work. And just because something is hard work doesn't mean it might not
also be worth doing

> 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.

I want to give the devil his due here. I happen to agree that
understanding the tasks users have to perform is the sine qua non of
good technical writing. Personally, I don't have confidence in
procedures I write if I haven't had a chance to DO them myself. Nor
have I ever seen good procedures written by someone who hasn't
attempted to do what they've written.

I don't agree that one can learn everything a reader needs simply by
being the user. Writers come to tasks with a different mind set than
their audience has. Surveys can provide valuable data if they are
constructed and applied with some discipline.

> 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.

True, BUT spending some time thinking about what you are doing and who
you are doing it for is as useful as the actual writing is. Neither is
complete without the other in a well-executed documentation plan.

> And as we all know: it is impossible to write a meaningful document
> without an intimate understanding of the topic/subject matter.

Again, true, BUT I've seen plenty of documents that were not written in
a manner that was useful to their putatively intended audience because
no one bothered to consider what the user needed, or wanted, to know.
(The two are not always the same.) If I put all of the technical
information in a document, but I do so in a way that you can't find
WHAT you need WHEN you need it, I've done as bad a job as if I had left
out critical information because I was sloppy in learning the technical aspects.

Tom Murrell
Senior Technical Writer
Alliance Data Systems
Columbus, Ohio
mailto:trmurrell -at- yahoo -dot- com

Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!

Previous by Author: Re: TM or R?
Next by Author: Re: Looking for sample questions for a survey
Previous by Thread: changing display units
Next by Thread: Re: Just do it (Long & Occasionally Sarcastic)

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

Sponsored Ads

Sponsored Ads