Re: Scoping a DocumentationProject??

[Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>]

Yes, Tony, this is exactly what we've been trying to convey. In a 
community of techwriters we are very focused on our audience, our end 
user. We come at all communication problems with that end in mind: how 
does this help my reader use and enjoy this product? We always start a 
project by thinking about the audience. The engineering folks start by 
thinking about the system. Both communities are needed to make a product 
work for the customer. Emphasis on one point of view to the exclusion of 
the other creates problems for the user. Systems-only focus leaves a 
legacy of hard-to-understand documentation. Techwriters are user 
advocates, we think and speak user, not system. It is not surprising 
that the requirements engineering community does not do this. That is 
not their primary role.

In a great development company, you have systems analysts, business 
analysts, and techwriters working together to figure out how the *system 
*can help the *user *do their *business*. Our profession has long argued 
whether someone should be an engineer first before becoming a techwriter 
so that they can understand the system, or whether they should be a 
plain language/communication expert first so they can explain the 
system. That debate will *never *be resolved because both are viable and 
valuable ways of approaching documentation. Each user community, each 
product, has its own needs and challenges. Techwriters tackle them all. 
That's why we are such a diverse group. There's a place in the 
profession for everyone who wants to be here, no matter what their 
background, because ultimately it's all about helping the user have a 
better experience with the product, process, policy, or service.

--Beth

Tony Markos wrote: