TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: How to edit constructively? From:"Jared M. Spool" <jspool -at- UIE -dot- COM> Date:Sun, 10 Mar 1996 20:56:43 -0500
On 28 Feb 96, Glenda Jeffrey wrote:
> Can anyone post some suggestions on how to edit a writer's work so
> that you help the writer to improve? That is, what is the best way
> to supply constructive criticism?
We don't write manuals, but we write reports and articles.
We're all engineers by trade, so we don't have any decent writing
training. We have picked up a couple of techniques that have served
us well.
We play a little game called "Bring me a rock." This is based on an
old story about how someone was asked to bring them a rock, then
when they returned they were given more requirements: "Needs to be
more blue." Upon each new return, they are given one more
requirement. "Not big enough."
Now, this seems like the wrong way to do things, but we've found that
if you know up front that the rock you are likely to bring back is
not going to be accepted, you won't spend too much effort finding it.
You'll find the first rock that matches the current list of
requirements and bring it back without looking for the "best rock".
In our writing, we often don't know what we are looking for. Also,
our problem is usually not the grammar or style, but the content. So
our initial rocks are all content based. We don't worry about style
or grammar until way into the process.
The idea is that the writer is told "write an article on how
tutorials can be improved" without much more guidance. They then
need to do the research and propose an article. They initially focus
only on the meat of the article.
We typically expect the first rocks to be less than a page. If the
writer writes more than that, we teach them how to bring "smaller
rocks."
Our experience tells us that the more "iterations" we go through, the
better the piece. So, we shoot for smaller, more focused iterations
instead of trying to "get it right the first time."
It also has the effect of making the piece more collaborative. While
only one person can be the primary author, each of us gets a say in
the content (and eventually the style) of the piece.
Another technique that we've learned is to avoid any grammar & style
criticism in the first "rock." While it is often tempting to go on
the Passive Voice Hunt (as we call it,) we resist that urge. The
first rock is explicitly reserved for content only comments. (In our
experience, there is nothing more disconcerting than to submit
something for review that has tentative content -- "Am I going in the
right direction?" -- only to get comments on sentence structure and
spelling.)
Hope you found this to be useful.
Jared
==========================================================
Jared M. Spool User Interface Engineering
jspool -at- uie -dot- com 800 Turnpike Street, Suite 101
(508) 975-4343 North Andover, MA 01845
fax: (508) 975-5353 USA
If you send me your postal address, you'll get
the next issue of our newsletter, Eye For Design.
==========================================================