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: Magical Thinking and Grimoires From:"Martin, Chuck" <chuckm -at- EVOLVESOFTWARE -dot- COM> Date:Wed, 14 Jan 1998 14:44:18 -0800
On Wednesday, January 14, 1998 2:35 PM, Kelly Anderson
[SMTP:kellya -at- VIEWSOFT -dot- COM] wrote:
>
> As I write technical documentation, I always try to get my user to
think
> about the problem in the same way as the designer. While this may
involve a
> little more up front time in learning to use the product, if the
correct
> "mental model" is achieved in the mind of the user, it is likely to be
> worth the initial pain.
But isn't that backwards? Shouldn't the design of the software reflect
how a user will solve the problem? That way, You don't have to "get"
users to think in any way other than they already are.
That way, you start with a design that attempts to match the users'
mental models. You also have to write less documentation explaining just
how the design is supposed to accomplish a user task.
>
> Unfortunately, in software, programs are often written in such a way
that
> the correct mental model is obfuscated. The programmer implemented it
as an
> "A", but tries to show it to the user as a "B" (which it really
isn't). We
> as technical writers ought to show the user that it really is an "A",
and
> that if they think of it as an "A" they will understand that it really
> isn't magic.
Actually, software is too often written within the mental model of the
programmers, who are *not* the eventual end users. That's why it's
important to think of ourselves as more than writers, to understand that
a large amount of the documentation is within the design, and to begin
involvement early in the design process, bringing usability and early
prototyping processes into the mix so you'll have a better,
easier-to-write-about, and easier-to-use product.
--
"You don't look American."
"Everyone looks American, because Americans are from everywhere."
- Doonesbury
Chuck Martin, Technical Writer
Evolve Software | Personal
chuckm -at- evolvesoftware -dot- com | writer -at- grin -dot- net
www.evolvesoftware.com | www.grin.net/~writer
