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.
PS. forgot to add something important: if your'e going to do
walk-throughs, it's best to plan them into the project schedule from the
very beginning. that way there's no questions asked. it's just part of
the documentation process.
> ----------
> From: Kathryn Marshall[SMTP:kmarshall -at- MODACAD -dot- COM]
> Reply To: Kathryn Marshall
> Sent: Tuesday, June 02, 1998 12:52 PM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Re: Walk-throughs
>
> Kate,
>
> We're trying to implement walk-throughs in our documentation review
> process. Trying. I've only had one so far. I lured people in with
> cookies and soda. The actual review process didn't go as well as I had
> hoped. At first there was a lot of dead silence. I wasn't sure how to
> conduct a walk-through and they weren't sure what to say. When we
> finally did get going, we kept going off topic (discussing new
> features
> or bugs) and I had to struggle to keep everyone concentrated on the
> task
> at hand. About halfway through, the engineers started getting antsy
> (by the way, there were 2 engineers, a Development Manager, a Product
> Manager, and QA person present).
>
> Like someone earlier suggested, you really need to make upper
> management
> understand why this is important. Do some research, write a report,
> conduct usability tests, make a presentation---whatever you have to do
> to get the point across. Be thorough and professional about it (of
> course) and set an example. Make them understand that the manuals are
> part of the product.
>
> I suggest scheduling the walk-through meeting (set aside ample time).
> Make it a requirement that people be there. Have your walk-through
> planned out. (I didn't and should have.) For example, do you make
> people
> read each page? Do you discuss the most recent changes that you've
> implemented? Or do you discuss the contents of a page or chapter and
> invite them to comment? (or a combination of all of these). Maintain
> control of the meeting at all times. When you're done, make everyone
> sign-off on it to make it official.
>
> This is a great topic. I hope more people contribute. I would like to
> hear a summary of responses.
>
> -Kathryn
>
> > ----------
> > From: Kate Skilton[SMTP:KNSkilt -at- ACCUSORT -dot- COM]
> > Reply To: Kate Skilton
> > Sent: Tuesday, June 02, 1998 6:49 AM
> > To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> > Subject: Walk-throughs
> >
> > Hi all -
> >
> > I was wondering if anyone out there had ever conducted a manual
> > walkthrough, either in the preliminary or final stages. I'm looking
> > for a different approach to our walkthroughs. I work for a company
> > where nobody wants to sit down and dedicate a few hours to the
> > quality of our manuals.
> >
> > Ideas anyone?
> >
> > Kate Skilton
> > Engineering Technical Writer
> > Accu-Sort Systems, inc.
> >
> >
> > &^~~~
> > Send commands to listserv -at- listserv -dot- okstate -dot- edu (e.g., SIGNOFF
> > TECHWR-L)
> > Find TECHWR-L-related books at
> > http://www.raycomm.com/techwhirl/books.htm
> >
> >
>
> &^~~~
> Send commands to listserv -at- listserv -dot- okstate -dot- edu (e.g., SIGNOFF
> TECHWR-L)
> Find TECHWR-L-related books at
>http://www.raycomm.com/techwhirl/books.htm
>
>
