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.
At the very least ensure your "interview" is listed on the project plan.
Surely the development of your product or a revision is planned and
scheduled using some project management tools such as Microsoft Project. If
your process is not chaos but is actually planned, I'd advise the writer
understand the project management process in use, too, and, again, ensure
the interview is a defined milestone.
Given that, I'd suggest something other than "interview." I think it would
be better to make it "demonstration," that is, a session with the SME where
the SME demonstrates the product to the writer. (This of course assumes the
SME has some idea how the product will be used by end users, but that should
be a reliable assumption or you're in big trouble beyond the scope of this
e-mail message.) I think this has more positive psychological impact than
"interview," as "demonstration" allows the SME to show off. In addition, it
would be good if the writer has tried the product prior to the demonstration
and listed some questions, i.e. things to learn at the demonstration. (Also
a list of things to compliment the developers/engineers for having created.)
After all, the final users aren't going to read the manual unless they're
forced to, and you will find yourself in their shoes by performing this
pre-SME interaction experiment.
Finally, as I was taught by the late, great company Communitec, for software
projects it could be feasible to think of an outline of the user manual as
mirroring the project plan for development of the software. That is,
develop the manual outline as one of the first project milestones to occur
near the beginning and before much coding happens. Then, the writer doesn't
have to be the last step in the plan (most always a bad idea but a common
"challenge") and can create partial products in step with the developers.
In fact, using this method, the writer can influence the final design should
interim designs prove user unfriendly or the like. Work in progress
demonstrations.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See http://www.infomap.com or 800-463-6627 for more about our solutions.
---
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 http://www.raycomm.com/techwhirl/ for more resources and info.
