"Design" was Re: Tech Writing a Growing Field?

[Chris Borokowski]

Someone else on this thread pointed out that tech
writers, as those who experience the corporate
environment and production process as a whole more
than others, have a bird's eye view of how development
progresses. They are attuned to aspects of the product
and the process that do not intrude into the
specializations of others.

It seems we are saying very similar things, you and I
and that someone. Technical writers are those who must
make the product make sense in the end, so they are
also those who know along the way what inconsistencies
must be quashed. It seems to me that as software has
gotten more inconsistent, this role has become more
important, especially as project managers get more
deeply specialized into managing the project, not the
product, and marketing gets increasingly detached from
the complexities not just of the product but its
interaction with other technologies.

In other words, like all things, technical writing
changes over time, and it makes sense to look toward
the positive aspects of that change: being able to
take our personal knowledge repositories and apply
them during the process of development for the
betterment of the user(s). This is where user
advocacy, information design and technical writing
meet.

--- Ned Bedinger <doc at edwordsmith.com> wrote:

> I think this point of yours harks to tech writer
> manifestos that want us 
> to be integrated into the full product development
> cycle. I need to 
> steep in a project to become an integral part of the
> design process. I 
> do subscribe to the theory and practice of long-term
> project membership 
> for tech writers (even when it means working in the
> crossfire of 
> marketing, development, and testing), but I think
> the design analysis 
> functions you mention (making sense of design
> process, distilling it 
> into logical maps) don't fit with the documentation
> role.
> 
> 
> Here are a few initial thoughts on tech writers and
> our brand of design, 
> which I mean in the sense of information design, not
> geometric 
> decorations, fancy fonts and rubric, or whatever.
> 
> 
> I do think tech writers are exposed to the vagaries
> of having to write 
> even when the project's requirements and design
> phases have been done in 
> mushy, unsatisfying ways. This is what drives an
> awful lot of 
> information design problems, and is a root cause of
> mushy, unsatisfying 
> documentation (MUD, in shorts).
> 
> 
> I also think tech writers are likely, over time, to
> become sensitized 
> and alert to problems that begin with and propagate
> from weak 
> development of the project's requirements and
> designs.
> 
> 
> But for tech writers, design is something that we do
> in order to be able 
> to work with poorly specified projects/products. It
> is different (even 
> as a process) from what other designing members of
> project team do, for 
> example what product architects and engineers do.
> 
> 
> Bottom line: I'm willing to articulate my design
> process, and I imagine 
> it is analytical enough to provide some leverage to
> other team members. 
> But I don't see how I would know or articulate THE
> design process that 
> might be influential or of working value to product
> architects and 
> engineers who design their own contributions.
> 
> 
> So, in this framework, I wonder if you are saying
> that tech writers 
> should try to drive the requirements and design
> phases because we're the 
> test case--if we can't find the information needed
> to understand the 
> product and project, then something is wrong and
> needs to be fixed first?



User Interface design blog
http://user-advocacy.blogspot.com/
Code::Design::UI::Consulting
http://www.dionysius.com/


 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/