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.
Subject:Re: Doc Design and Conventions From:Robert Lauriston <robert -at- lauriston -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Sat, 31 Oct 2009 10:18:28 -0700
I think the main qualifications are the ability to learn whatever
you're writing about quickly and the ability to explain it in plain
English (or whatever kind of English is appropriate for the audience).
At least in software, I think good tech writers end up knowing a lot
about UI design because we have to compensate for bad UI design. I've
often been the first person to actually approach a product from the
perspective of an end user, and have logged a zillion usability issues
about sloppy ad-hoc design by programmers who didn't really understand
who would be using the product to do what.
I have more than once documented ~40-step procedures with the main
goal of persuading the product manager that the UI needs to be fixed.
I'm not sure what you mean by "largely makes procedures obsolete."
On Fri, Oct 30, 2009 at 8:15 PM, Janoff, Steve
<Steve -dot- Janoff2 -at- teradata -dot- com> wrote:
> Hey Chris,
>
> Your post inspires me to want to delve into the origins and history of
> tech writing.
>
> It seems odd that tech writing has evolved from probably a simple
> beginning of written communication to the point where the writer is now
> intimately involved with user experience design. That's not a bad
> thing, it's just curious.
>
> What qualifies a writer to perform this role? Is he/she the advocate of
> the ordinary person? Is the writer somehow more "human" than the
> developer, and therefore able to talk to the user in that person's
> cognitive language?
>
> I remember the days when you had to fight to get a word change into the
> UI -- writers were not allowed to contribute in any way to the
> interface, even from a language standpoint.
>
> Now our ideas are welcomed, even solicited, regarding functionality,
> user experience, usability, interaction design, navigation design,
> screen layout, information architecture, and the rest of it.
>
> Innovators aren't always good writers, and writers aren't always good
> innovators. If our role largely makes procedures obsolete, then what
> *is* our role?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you looking for one documentation tool that does it all?  Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
