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: intuition vs. background From:Len Olszewski <saslpo -at- UNX -dot- SAS -dot- COM> Date:Wed, 5 Jan 1994 13:28:49 -0500
Tracey Showalter discusses intuition:
> Earlier in this thread I was wondering if many people -- especially a few
> product marketing and upper management people I can think of -- translate
> intuitive as how well the interface meets the background of the user: things
> such as culture and job and industry experience. If you'd never seen a garbage
> can, how much sense would Mac's trash can make? Ditto for folders and files.
> Does this lead to the possibility of levels of intuition, which is definitely
> counter to the definition of intuition?
This is an interesting thread, isn't it?
I just *know* that in the respective cases of each of the listmembers,
some developer somewhere insisted that a software product was intuitive.
No doc needed. Go ahead, write one anyway if it makes you happy.
Here's what was intuitive - the *writers* were intuitive enough to write
a lucid manual and/or help system with zero source material documenting
all of the stuff the developers thought was intuitively obvious. (I've
been there and back, and am living there now - does it show? Sorry.)
Everybody has a different degree of intuitive ability. When a developer
says a product is intuitive, that's probably right. It's intuitive all
right, *for the developer*. Unfortunately, the developer doesn't buy the
product. You need customers for that end of the business. Is the product
intuitive for *all* prospective customers, Mr. Developer? Well, is it?
(You too, Ms. Developer; I ask equal opportunity rhetorical questions..)
It seems there is a continuum along which you can mark the intuitiveness
of a product relative to any given user. Products are rarely completely
intuitive or completely opaque. Experienced users only read the "special
topics" sections in manuals (that's why you need to put them in where
your power users can easily find them). Beginners who use the same
product live with eight or nine manuals open at the same time, clicking
on hyperlinks and invoking context-sensitive help, when they can find
it. Is the product intuitive or not? Depends on who you ask. You can
accomodate both ends of the spectrum with different manuals, or
different sections in the same manual, even if your product only covers
one of the extremes. That's why tech writers are so important (well,
that's *one* of the reasons...).
There's a little trade-off you make during the design phase, when you
decide who you think comprises a larger portion of your potential
market, and you make the product please that segment more (or piss it off
less) while annoying everyone else. The writers come in and explain it
all after the design decisions have been made (usually), but the users for
whom you designed the product are the winners. Power users hate the
performance hit and the hoops when they see GUIs with all kinds of help
files. Beginners won't touch an otherwise screamin' product with an
interface consisting of blinking cursor and a "ready" prompt. Everybody
else copes as best they can.
Did you guess right during the design phase? Are the users you
accomodated the same ones who are buying the most copies of your
product? Do you need to make other market segments happy with the next
release? Are you interested in backwards product compatibility or
rewriting a bunch of existing manuals? Why does the phone always ring
when you're in the bath tub?
No, it's not easy. It looks easy, but it's not, it's not easy. Easy to
say, hard to do. You need usability tests for the product, for the doc,
for the help, for the online stuff, good beta sites, market research,
committed staff, smart management, talented writers and developers who
work hand in hand, enough time and money, you know - all the usual
Ok, I'm finished. In retrospect, I said a lot of obvious things I guess.
Oh well. Later on, everybody.
|Len Olszewski, Technical Writer | "Never confuse motion for action." |
|saslpo -at- unx -dot- sas -dot- com|Cary, NC, USA| - Ernest Hemingway |
| Opinions this ludicrous are mine. Reasonable opinions will cost you.|