Completely intuitive, no; intuitive, yes!

Subject: Completely intuitive, no; intuitive, yes!
From: Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA>
Date: Tue, 8 Jun 1999 08:12:07 -0400

Karen Peterson <<... recommended that a certain function be
changed, because the users consistently did not understand it.
The overwhelming response from the developers was that it's
impossible to create software that's completely intuitive; the
user must read the manual.>>

The most satisfying response: "Yes, that's true, but it doesn't
take any more effort to make something relatively intuitive in
the first place than to program the same function
counterintuitively." Of course, if you have to work with these
people for any length of time, you might want to adopt a
more diplomatic approach.

<<It was my impression that the current tech-writer-favored
trends were to make the software functionality and the UI as
intuitive as possible, weaning the user off documentation.
Was I wrong?>>

Yes and no. Yes, because it's unlikely we'll ever have
interfaces so intuitive and so packed with affordances (cues
and clues) that documentation is wholly unnecessary; no,
because the goal really is to get as close as possible to no
documentation as possible. The only way to get there is to
make the documentation part of the interface to whatever
extent is possible.

<<I was just trying to get the project lead to make changes to
the interface rather than always saying, "Just explain it in the
manual" or "Once they do it wrong, they'll learn not to do it
that way again.">>

The usual cause for this problem is not programmers who are
actively hostile to the users; rather, it's programmers who
haven't been convinced by their bosses that satisfying the
needs of the user is why they're employed. That, and the fact
that most developers seem to be under spurious deadline
pressure and believe (usually incorrectly) that the underlying
code is so much more important than the interface that they
can ignore the interface. Obviously an intuitive but buggy
interface isn't desirable, but usability and the ability to
function correctly are both important.

Ideally, the message comes down from on high, and the
programmers ignore usability testing at their peril. More
often, you're the one who has to make the sales pitch. You
have to know your developers well enough--and have
enough credibility and accumulated credit with them--that
you can browbeat them into accepting a compromise of some
sort: maybe not your specific solution, but at least a step in
that direction. What's worked for me is that I know a
reasonable amount about programming, even though I
haven't programmed in years; thus, I can ask them how their
algorithm works, and once I know that, I can propose an
alternative that makes the interface easier to program and
more usable. In fact, one of my prouder moments was
suggesting a better underlying algorithm (equally performant,
but easier to maintain and implement).


--Geoff Hart @8^{)} Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"The ability to speak does not make you intelligent."--Qui Gonn Jinn

From ??? -at- ??? Sun Jan 00 00:00:00 0000=




Previous by Author: Landscape vs. portrait?
Next by Author: Getting published at work?
Previous by Thread: Re: Performant - is it a word
Next by Thread: Word 2000 and techwriting


What this post helpful? Share it with friends and colleagues:


Sponsored Ads