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.
My second tech writing project was a contract position where I was the lone
tech writer with a company that had absolutely no existing documentation or
specs, aside from the application itself (yet another handicap of
startups!). I began documenting each widow, field, menu option, and any
other feature of the app without understanding the actual business processes
that drive them. Although it involved a lot of tedious work, this
"preliminary" doc provided the starting point to began investigating.
My next step was to propose the creation of a "standard" set of
documentation that accompanies most software (depending on the platform and
development tools), to the development staff and the sponsoring business
groups. As it was a web based app, the docs I suggested were:
This initial proposal is my archetype approach, and served as the starting
point for discussion where, as a group, the development and business side
reps decided what was necessary, what was nice to have, and what was
completely unnecessary. If your client doesn't know what they want, I found
that making recommendations forces them to think about what they really need
before the work begins. For example, during this proposal meeting (which
turned into a brainstorming session), they also realized they wanted entity
relationship diagrams as well. This meeting was also an excellent
opportunity to identify the priorities of each doc/diagram, as well as
responsibilities.
Based on their newly discovered requirements, I began the documentation
process. Unfortunately, due to a lack of structure and direction from the
client, I did more research and leg work than I would have done in a
traditional development environment, but my input and counsel were highly
valued, since I knew much more about the product than many of their
employees.
This type of a documenting environment can be frustrating and a struggle,
but starting with a "tabula rosa" can also be enjoyable, because you have
much more freedom in terms of the presentation format and the actual content
of each help doc. Tech writers could use a little creative freedom now and
then to keep our sanity, so this might be one way to see the good in your
tough predicament ;).
Syed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of
your book. What are you waiting for? http://www.iuniverse.com/media/techwr
---
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.
