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.
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).
