Re: User Interface Design

["Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM>]

At 10:47 AM 8/15/96 -0500, Karen Mayer/Touch Technology wrote:

>I'm struggling (again? still?) with some of the ways things are done at my
>company. The thing that has me concerned most these days is what I consider to
>be a very poor user interface design. It irks me that we tech writers were not
>consulted on the design in the first place, and now we have what used to be a
>prototype that just evolved into the final product. And it's embarrassingly,
>frustratingly inadequate.

>I wonder how many of you software documenters are consulted in the user
>interface design process. Do you have a lot of input? Do you have any
>guidelines for what constitutes a good UI design? I've got some ideas for a
>better UI, but I haven't much training or education (self-inflicted or formal)
>in UI design. Can you recommend any books?

Karen,

There are very few companies in which technical writers are automatically
consulted about user interface design. Nobody ever thinks of this on their
own. If you want to become involved in user interface design, you have to
force your way in. And, yes, I too have seen the easy-to-use prototype
evolve into the user-interface-from-hell in no-time flat just because the
programmer had a really good idea and took off with it.

Most of my UI training is self-inflicted. Some of it came from STC
presentations and seminars. And there's lots of good information on utest,
too. Reading starts with Don Norman's _The Design of Everyday Things_,
proceeds through Jeff Rubin's _Handbook of Usability Testing_ to anything
written by Jacob Nielsen (of Sun Microsystems). The newest STC Journal has
an excerpt from _About Face_, which I haven't read yet and I can't remember
the author's name (Cooper, I think), but it comes highly recommended.

Also, get your hands on the programming style guidelines for whatever
platform you're documenting. These can usually be located on the bottom
shelf of the lead programmer's bookshelf, right behind the 8" diskettes.  ;-)
Wait until the surf's up and all the programmers are out of the office,
then go looking.  ;-)

Ok, you've done your reading, you've got a better idea, now you have to
muscle your way in. This can be more or less difficult, depending on the
group you work with.

Step 1:  Check the user interface for standards. You're a technical
writer, so they'll expect you to check for grammar, spelling, punctuation,
and the like. Also check that double-clicking is implemented everywhere,
that hot-key combinations are implemented everywhere, that the tab
sequence through the dialogs are logical, that display-only fields are
presented correctly (i.e., with a gray background instead of white), etc.
File honest-to-betsy bugs against everything you find. Site the design
standards by page number, if necessary.

Step 2: Do a heuristic usability analysis (Jacob Nielsen has a book about
this but, sorry, I forget the name of it). Make sure that the dialogs can
be logically traversed and that cursor movement moves left to right and
bottom to top (unless, of course, the program is written in Japanese).  ;-)
Are the field labels clear and unambiguous? Stuff like that. Again, file bugs
against everything you find.

Step 3: Create that better design using Visual Basic or mock it up in
Paintbrush or sketch it out on paper. Talk to the developer about it. He
may actually react favorably. (hey! It *could* happen!) Offer to usability
test the interface with a couple of local beta testers. What? You've never
done that before? There's always a first time! You'll learn.

The point (sorry I got so carried away) is that nobody is going to *ask*
you to get involved. You have to express an interest, display some knowledge
about the subject, and generally muscle your way in. I firmly believe that
technical writers should be intimately involved with every aspect of the
program that communicates with the user, and this includes the user interface.
But we have to grab that territory. Nobody's going to *give* it to us.

TRMOAS:
When I worked at StarBase, the primary project architect was extremely
resistant to having tech writers involved in UI design. It was a proprietary
thing with him and there was just no convincing him otherwise. Marketing
asked him to participate in a focus group at which they displayed the
prototype for a new product. One of the focus group participants told him
that the prototype's UI could use some work, then said, "Why don't you ask
your technical writer to help. They're usually pretty good at that."

He was a long time living down that comment!  ;-)

Sue Gallagher
sgallagher -at- expersoft -dot- com
     -- The _Guide_ is definitive.
        Reality is frequently inaccurate.

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-