Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!brunix!doorknob!rsw
From: rsw@cs.brown.EDU (Bob Weiner)
Newsgroups: comp.human-factors
Subject: Re: rules of thumb
Message-ID: <RSW.91Jun27053332@tahiti.cs.brown.EDU>
Date: 27 Jun 91 09:33:32 GMT
References: <1991Jun26.092540@axion.bt.co.uk>
Sender: news@brunix.UUCP
Organization: Brown U.
Lines: 50
In-reply-to: jpope@axion.bt.co.uk's message of 26 Jun 91 08:25:40 GMT

In article <1991Jun26.092540@axion.bt.co.uk> jpope@axion.bt.co.uk (john pope) writes:

> 
> A lot of the discussion in this group seems to be bitty:
> ie I don't like this, I don't like that.
> 
> I wonder if anyone has any general `rules of thumb' for
> considering human factors when designing products.

* Follow a process like:
	analyze user needs
	design
	test on REAL, naive users, not techno-wizards
	iterate-design
	iterate-test
	...

   User testing is essential and all too often left until it is too late.
   Novice, medium, and expert user feedback is all invaluable.

* Try it yourself.  Seems obvious, huh?  How many people at Microsoft can type
command-option-shift-t with verve on a Macintosh?  Yet, they seem to put such
things in all their programs.  (The answer, I believe is that many of them
remap their keyboards and so never deal with what they show their user base.)
If you're a keyboard junkie, make sure you doubly test your mouse interface.
You can generalize these ideas for other types of interfaces.

* Employ natural or familiar metaphors accurately.  This allows people to draw
on their prior experience and thereby become comfortable with the interface
more rapidly than if they have no grounding with which to decide how to operate
elements of an interface.

	Example to emulate:  Go Corp's use of notebook section dividers (tabs)
	   which when selected/touch, flips the view of the notebook to the
	   starting document page associated with the tab.

	Example to learn what not to do:  Apple's decision to use the garbage
	   can icon as a means of ejecting floppy disks.

* Embed deep (as opposed to surface-level) customizability in the product and
its interface.  Otherwise, people with experience won't be able to make your
interface operate in a way they are used to and so most likely won't take full
advantage of it.  Such a requirement can also drive you to create more modular
and coherent designs.

* Minimize the focused attention needed to operate your interface (unless it is
a proficiency testing or minimal capability testing device.

--
Bob Weiner				   rsw@cs.brown.edu