RE: Advice for writing a user manual/documenting businessprocess

Subject: RE: Advice for writing a user manual/documenting businessprocess
From: Sean Hower <hokumhome -at- freehomepage -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 17 Apr 2003 14:14:23 -0700 (PDT)

If you want advice and tips on interviewing, I can talk your ear off. :-) check for previous posts by me on the subjects of: site visits, contextual inquiry, enthnography, and open-ended interviews. This is a PERFECT case for conducting a little contextual inquiry. Here's some things to keep in mind:

* Don't ask the people you interview "what do you do?" or "Why do you do XXXXX?" People generally can't give you an answer because they haven't thought about it. People also tend to report one thing and do a different thing. It's not malicious, it's just a person's perceptions of what they do and what they are actually doing are usually different.

* Watch what the people are doing. Watch them. Just sort of melt into the background. Someone suggested video taping, and if they would let you do that, that would be great. Take lots of notes. You can ask questions about why they perform a specific action, but don't expect a clear answer.

* Plato talked about doing the job for a while, and that's actually a very very good idea. You'll get your hands dirty, you'll get a feeling for what your users are doing. You don't have to do it for a week. A day would be enough, two would be even better. Just as long as you get a good idea of what it's like to work at this place and to do the job they do.

* Interview management to find out how things are supposed to run, because you can bet that the way things actually work will be different. Getting the info from management will give you a chance to understand where management is coming from, and get you a better idea of what they are looking for, while hanging out with the grunts will get you a better understanding of what works and what doesn't work. Eventually, though, you will rely on your observations with the grunts and not on what management has told you (if the docs are for the grunts that is). If there is a big difference between how management says things work, and how things actually work, be careful because such information might get people in trouble.

* Take notes.

* Have someone who your users trust introduce you, have the person warn the users ahead of time that you're coming so that there are no surprises.

* Explain what you're doing, and explain how the person will benefit from participating.

Blah blah blah. I can give you more pointers, so if you want you can email me.

Hope this helps.

"And in the morning, I'm makin waffles." ~ Donkey
Sean Hower - tech writer

Create your own web site for FREE at

Select your own custom email address for FREE! Get you -at- yourchoice -dot- com w/No Ads, 6MB, POP & more!

Purchase RoboHelp X3 in April and receive a $100 mail-in
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.
Order here:

Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....

You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit for more resources and info.

Previous by Author: re: Tech Writer Job Advert (humour)
Next by Author: book: Single Sourcing: Building Modular Documentation
Previous by Thread: RE: Certification is absurd
Next by Thread: UPDATE: The humbling reality of writing multi-page articles

What this post helpful? Share it with friends and colleagues:

Sponsored Ads