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.
Maybe users are telling us something we don't hear when they do not use the
tools we create for them. They may be telling us:
Your manuals aren't helpful
Your Help isn't helpful
Your product ought to make it obvious what I should do
I firmly believe that all documentation is a poor substitute for a well-designed
product. Technical communicators need to spend far more
time building relationships with product developers and influencing them to
create self-documenting, intuitive products that don't need 300
pages to explain the basics. And true, there will always be products that are
just too complex to achieve this, and so yes, we will need to
document these. For those products, let's focus on finding out what users do
find helpful and produce that. This means LOTS of usability
testing, lots of listening to people, lots of watching people work, and lots of
time developing the technology that lets us do what people
want done. Windows '95 will have some nice tools that allow us to give people
instant Help without their having to ask for it, but we need
to learn what they will need help with by studying how they do things.
