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.
> -----Original Message-----
> From: Mike West [mailto:Mike -dot- West -at- oz -dot- quest -dot- com]
>
> > > If companies don't want to spend money on user
> > > analysis, and if the user isn't interested
> > > in being analysed in the first place, then
> > > what can you do?
> > One way to learn more about your users when you
> > have no budget and no pet users: Try talking to
> > tech support .. <snip>
> That's one good way. Reading and research is another.
> Talking to the people who actually conceived and
> initiated the programming project is another -- they
> almost always had a specific business need in mind
> when they started.
Yes, it's a good idea to know what the problems are that this software
solves, and what the specific tasks are that it enables its users to do.
Beyond that, you are writing a white paper, not a user guide or
technical document.
> The hacks cutting the code may
> have little idea about *why* they are doing what
> they've been asked to do, but *someone* in the
> organization knows the use cases that the product
> is supposed to solve.
Well-written use cases are a beautiful thing.
> Those are the people who
> can teach you about the users. These may be in
> engineering, or in sales, or in the CEOs office. But
> you can bet that the owners of the business are
> not spending money on development without some
> idea of who their customers are and what business
> needs the product is supposed to satisfy.
Er, you might be surprised. <g>
However, disappointment in this area should not prevent you from setting
things right by writing docs that enable users to get value from the
software. I like the idea of thin, practical docs that address ONLY what
the user needs to know to use the software. Keep the sentences short,
the procedures direct, and the focus on providing the user with
direction that helps, not educates or fascinates. :-) Unless you're
Michael Crichton or Nelson DeMille. :-)
Tom
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from http://www.techsmith.com/rdr/txt/twr
Find out what all the other tech writers, including Dan, already know!
Order RoboHelp X3 in December and receive $100 mail in rebate, FREE WebHelp
Merge Module and the new RoboPDF - add powerful PDF output functionality
to RoboHelp X3. Order online today at http://www.ehelp.com/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 http://www.raycomm.com/techwhirl/ for more resources and info.
