Improving the UI

[Jim Purcell <jimpur -at- MICROSOFT -dot- COM>]

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,
>pizza?  What?

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

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.


Good luck!

Jim Purcell
jimpur -at- microsoft -dot- com
My opinions, not Microsoft's

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html