Re: 'Old fashioned' Tech Writers

[TechComm Dood <techcommdood -at- gmail -dot- com>]

> That's all well and good, John. But it gets complicated sometimes.

I'm sorry to disagree with you, but it will always and only be as
complicated as you choose to make it.

> Say you have an application that might be used by a thousand people in
> one company. Well, it's worth the investment to go learn as much as you
> can about how the people in that one company do their jobs.

Right.

> And the same application, with some configuration options set
> differently, might be used by a thousand people in a second company. And
> the way people in that company do their jobs (or even the level of
> computer literacy in that second company) might be substantially
> different from the situation in the first company.

True.

> Now add a third and a fourth a fiftieth and a hundredth company, all
> with slightly or radically different audience characteristics.

OK.

> But you have to document the application for the benefit of users you
> cannot possibly know about yet, back when you're writing help for the
> first company.

This is where the level of complication you cite can be avoided. 

There is a big difference between writing for your customers and
writing for your target user profile, or in other words, your target
audience.

You cannot satisfy your customers as a whole. It cannot be done. Why?
Because each and every person who makes up the collective "customer"
thinks and works differently.

Your "audience", as a technical writer, as a software developer, as a
engineer, is not a flesh and blood person. It is a profile with which
you build your business model/case and the profile to which you steer
your efforts. Sure, there may be people out there who nail your
profile perfectly or who come very close, but the point is not to
develop or document for EVERYONE... it's to develop and document for
your TARGET. If you hit your target, then you were successful. Those
customers who fall short of your target can then benefit from
additional consultative and training services.

> We can make certain assumptions about our users, and then we can revisit
> those assumptions later if circumstances dictate. Or we can write
> enormously more complex documentation, with conditional text tied to the
> configuration options set in the application, if we're willing to spend
> the time and money it takes to do that.

True, but you gotta consider the ROI.

> But what we cannot do, for most products, is know with any degree of
> certainty who the audience is going to turn out to be, at least not
> before the product is on the market for a while. 

And that is why most products to market eventually fail. 

> Nor can we easily apply
> some formula that tells us we're meeting the needs of the majority of
> our audience. 

That should not be your goal.

> I'm not by any means saying we can't meet the needs of the
> audience; writers do it all the time. I'm just saying that the writer's
> experience, judgment, empathy for the reader, skill with language, and
> willingness to revisit assumptions over time will get you a lot closer
> to your goal than methodology alone ever will.

What is your goal? 

I'll be blunt. My goal is to collect a paycheck so my kids can
continue dance lessons, have nice things, be garanteed a good
education, and vacation somewhere every summer. My goal is to provide
a better quality of life for my children than my parents were able to
provide for me.

I care whether or not my documentation is good, believe me. But do I
care if every person reading it benefits from it? No. I don't.

Does that make me a bad technical writer? Well, not to me, but you're
free to disagree.

> Does this mean that sometimes you include information about edge cases?
> Does it mean that sometimes the software itself should accommodate those
> edge cases? Maybe. It depends on the circumstances. If you can afford to
> ignore outliers as potential customers, great. If you can retrain those
> outliers to do their jobs the way other people in the same industry do
> them, great. If not, maybe you accommodate them, given a large enough
> potential sale.

I think the question is better phrased "can you afford to accommodate
outliers". The extra mile doesn't come cheap, and that last mile forks
in a million directions. The more you work to accommodate everyone,
the more work you create for yourself in the long run. Unless you are
100% services bound, choosing to cater to the outliers is a very bad
idea. Let the 3rd party chop shops care for your outliers. Focus on a
strong core.

> I'm all in favor of making tech writing as simple and formulaic and
> mechanistic as it can be--so long as it is still effective. But there
> has to be a writer in the loop, too, who can apply judgment (call it
> experience-meditated intuition if you like) and skill, too.

And I agree. But this is not at all bound to everything previous you wrote.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l 

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.