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: Getting Information From:Marilyn Flax <Marilyn_Flax -at- PRESENCE -dot- COM -dot- AU> Date:Fri, 18 Jun 1999 14:44:17 +1000
How would you present a documentation presentation? I've been toying with
the idea but the developers are working to extremely tight schedules and it
may take too much time to describe the manual and then invite discussion.
Any advice?
My favourite way to get information is to observe users while they are
working, or sit in on training sessions.
My usual way is to figure the product out for myself - time consuming for me
but does not require time from developers. Then, after I know a fair amount,
I am able to ask developers more detailed questions, and they are usually
more willing to help when they see that I know what's what.
-----Original Message-----
From: Technical Writers List; for all Technical Communication issues
[mailto:TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU]On Behalf Of Michael Schiesl
Sent: Friday, 18 June 1999 8:16
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Subject: Getting Information
One of the most trying tasks that I've come across is getting information.
I
thought that I'd open a little discussion here...Here are some different
angles/strategies that I've cooked up to get information. If you have any
items
that have worked for you, I'd be happy to hear about them.
- Host a website. Place writing issues on the site and mail periodic
reminders
to developers, disguising them as a what's new this week report.
- Host a Lotus Notes database. Place issues online and mail reminders to
developers/etc. periodically.
- Show developers some model documentation. It may get them more interested
than just continual interrogation.
- Attend their meetings.
- Ask if you can qual test the product (say that you are testing your
documentation).
- Keep them informed of documentation efforts.
- Ask them to explain their efforts, knowledge, or technology (you may hit a
gusher).
- Ask them how the product works.
- Ask some specified questions.
- Invite them to a documentation presentation.
- Ask for a product presentation.
- Ask for a product demonstration.
- Hand out surveys/questionnaires.
- Keep yourself visible to them. If you do not sit by them, make sure to
take a
daily stroll through their area. A periodic email/phone call will remind
them
that you exist.
- Get to know them. Become their friend.
- Become assertive. Don't be a bully, but do assert your aspects of the
business.
I always have to be new and creative in how I work with people. Please add
any
contributions that you may have.
Michael Schiesl
Rockwell Automation Product Documentation