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:Improving the UI From:Jim Purcell <jimpur -at- MICROSOFT -dot- COM> Date:Fri, 7 Mar 1997 16:30:40 -0800
Rikki Nyman asks:
>I get to start working on my first online doc project Monday. The few
>screens I have seen have some very strange names and very cryptic
>meanings; they will require a lot of explanation just so the user can
>understand them. The other technical writer says the programmers
>bristle when they think you are questioning their UI design. My
>question is, how can I guide them effectively in at least correcting
>some of the more glaring oddities without alienating them? Toys,
Bribery is not to be dismissed out of hand, but it should be a last
resort. Engineers always believe their UIs are logical and obvious. If
they didn't, they would design them some other way. Before you propose
an alternative, be sure that you understand the logic of what you are
arguing against. It may turn out that for the user of this interface,
what the engineer is doing is perfectly appropriate. Maybe the user
really thinks the way the UI works.
Then again, maybe not. If there really is a problem, keep the discussion
focused on the user. You will make a more convincing case for change if
you can show that, for instance, the engineer's logic is based on
software design (the usual case when there is a problem) and not the
user's needs in the task environment. Be able to demonstrate concretely
and in sufficient detail your understanding of general usability
principles and how they apply to this user and this task environment,
and be prepared to present your suggestions in that context. Don't get
all theoretical, but if professional scholarship is on your side, use it
to make your point.
Make your suggestions when they can be acted on. If the spec contains a
UI section, getting your $.02 in before the first screen has been built
is ideal. Reviewing early prototypes of the UI is still very good. By
the time the product goes to beta, the only things that will change the
interface are new features, showstopping errors, or overwhelming user
Above all, know what you are talking about. Engineers are not inflexible
sociopaths, but they do not always have a generous nature when faced
with uninformed or irrelevant criticism. Aesthetic arguments will carry
no weight unless aesthetics are important to the user. An interface that
confuses you is a problem only if you are the intended user; an
interface that confuses the user is a problem even if you understand it.
jimpur -at- microsoft -dot- com
My opinions, not Microsoft's