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.
I work for a small web-application company. In the past, our
documentation has primarily been what I can best describe as GUI
guides: walkthroughs on how basically to use the software. Our
customers are finding this inadequate (to say the least), but
it's all our salesmen know how to sell. We got bit recently very
badly when the line in the proposal said "technical docs/user
guides" - our salesmen figured that simply meant a standard User
Guide; our client meant User Guide, Admin Guide, and full
technical documentation of how the innards of the software
works.
I've been tasked with coming up with a *simple* questionaire
that our salesmen can use when they come to the 'documentaiton'
part of the proposal, to pin down more exactly what our
customers expect. Can anyone help me? Does anyone have a similar
questionaire that salesmenu use to scope out documentation so
it's bugeted for properly and not just as an afterthougth?
Currently, I have:
Document Title:
What type of document is it: GUI Guide, Reference Manual, Admin
Guide, technical specs, etc? (do I need to put in definitions of
types of documents?)
Audience: Who will use this document?
Category of use: general users? Administrative users
(administrating the database behind the software, for xample)?
Category of employee: Mechanics, clerks, managers?
Intent: how will this document be used? gui guide? training of
new employees in business process (using the application in the
context of a larger process)?
what is the scope of the document? GUI guide? placing the
software within the context of the external business process?
using the software within that context?
many thanks,
Becca Price
bprice -at- logiclink -dot- com
=====
------------------
becca -at- di -dot- org (primary address)
What is courage now?
Is it just to go until we're done?
Men may call us heros when they can say we've won
But if we should fail, how then?
--"Fellowship Going South", by Leslie Fish
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A new book on Single Sourcing has been released by William Andrew
Publishing: _Single Sourcing: Building Modular Documentation_
is now available at: http://www.williamandrew.com/titles/1491.html.
Help Authoring Seminar 2003, coming soon to a city near you! Attend this
educational and affordable one-day seminar covering existing and emerging
trends in Help authoring technology. See http://www.ehelp.com/techwr-l2.
---
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.
