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 writ:
> I am helping to design bug tracking software for our office. As a result of
> usability testing, I 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.
>
> I'm not debating whether or not we should have manuals or anything like
> that. 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."
Although I agree that it's essentially impossible to develop completely
intuitive software, I disagree with your developers' conclusion that you must
then prop up design challenges with documentation.
The word intuitive is so easily tossed about as a desirable software
attribute. But I don't think anything about software is intuitive. Instead,
I think that usage *seems* intuitive if it's like other software usage you've
learned before.
Even if you've learned enough software to make new software easier to learn,
bad interface design will still stop you. It's better to fix known usability
problems than to ask the manual to explain how to work around them.
I encourage you to write change requests (or whatever your company calls bug
reports) for the usability problems you uncover, and lobby hard for them to be
fixed. Other priorities might defer some of those fixes for another release;
in those cases, do your best to unobtrusively document around those usability
problems. I find that task-based approaches in which you simply lead them
through the messy usage work best.
Peace,
jim
===
jim grey / mobilene -at- yahoo -dot- com
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
