radical revamping of techpubs

[Chris Borokowski]

Bill's perception is quite correct, and I'm glad to see other agree.

The best TWs I know are the ones who happily roll up their sleeves,
dive into an unknown situation and get dirty. My mental image is of
them parachuting from a plane far above the unknown, getting last
minute shouted orders from a drill seargeant, then grabbing their
laptops and parachutes and jumping.

It's a lot like journalism (the first love in writing of many of us).
You have no idea what the situation is. Someone will hand you a press
release that tells you what one fraction of the equation wants you to
think. You must dig, find the truth of how the situation functions, and
put that down in the kind of description you'd use for a complex
design.

Right now, there's a massive convergence in technology because it all
uses the same basic interface elements. Web2.0 software is all server
based, but Web3.0 may be cloud-based, and in both cases, the basics of
the interface, networking and remote software interface are well known.


The old TW job would have been to describe these. The new one is to
give the users power over the application and show them how to become
power users. In other words, people are now familiar with the basics of
the task, so we have to show them a power user method that quickly gets
them up and running and dominating their most likely tasks. What we're
doing now is what aftermarket books did in the 1980s and 1990s.

In my view, technical writers should recognize that unless we adapt,
we're going to become specialized contractors called in when the real
work is done to write the manual (WTFM) and then skedaddle. What we
could be doing instead is throughout the life of the product, studying
how it interfaces with the user and making that process more facile.

In this new role, we'd be part journalist, part communicator, part
trainer, part project manager, and part interaction designer and user
advocate. This is to the benefit of writers, as we get to spend the
entire product development cycle getting to know it and get a more
justifiably necessary and lasting role, and companies, as they get
several roles in one.

--- Rene Stephenson <rinnie1 at yahoo.com> wrote:

> HA! Quite true! TW's usually also bring an approach that is closer to
> "green field" than the developers, engineers, etc., can provide.
> Because they understand how THEY INTEND for it to function and be
> used, they can be a bit myopic about how what they have CREATED
> actually plays out.
> 
> Rene
> 
> Bill Swallow <techcommdood at gmail.com> wrote: I'd say that those are
> additional skills. What I took Chris' remark to
> mean is that writers should be there through the entire process,
> involved with design, so not only do they influence the product
> design
> along with the other stakeholders, but also have a means of
> thoroughly
> planning the entire documentation effort as part of that product
> development planning. Let's face it, most tech writers come at a
> product from a different angle than an engineer or a tester. It may
> not always be user focused, but it certainly is from a task-based
> angle. "Is this thing going to be well thought out and therefore easy
> to explain or is this going to be yet another 100 page install
> procedure?"
> 
> 


http://technical-writing.dionysius.com/
technical writing | consulting | development

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com