Feedback to "Interfacing the User"- Murphy's Law,
Read the original artilce at Interfacing
return to Murphy's Law
Rob Withoff (Infrared Solutions) makes a number of interesting
I must take umbrage with your column on UI design, "Interfacing
the User". While you bring up some very valid points, you focus
on the concept that users would rather prefer a few canned options
than the ability to run the gamut of all available options, and
you specifically detail the ability for the user to configure
their own options as the designer "abdicating their responsibility"
in good UI design.
By taking this tack, you make the assumption that the end users
are a bunch of morons, or that the design should reflect the lowest
common denominator so that the maximum amount of people can get
the most use out of your design. This is exactly the same kind
of thinking that dominated network television sitcoms for decades,
and brought us the pablum that we watched (or refused to watch)
in our formative years.
The truth is that UI design should flow from the functionality
of the device being designed *before* the back-end design takes
place. Too often the user interface is an afterthought, constrained
by the physical or cost requirements of the design (we need to
have text entry capability, but we can only afford two buttons
and an LCD).
There are some general rules for good UI design that work well
in both physical and graphical UIs:
1.) One control, one function. The most user-friendly designs
follow the one-function-per-control rule. This is also the most
expensive and impractial for most embedded designs, so this is
modified into a guideline: minimize the overloading of controls.
Can you imagine trying to dial a cell phone if you had to enter
numbers through a menu (press SELECT, scroll through options to
NUMBER, select 0-9 from the list)? The corollary to this is "fewer
buttons don't mean a simpler interface".
2.) If you must overload controls (i.e. menus), generate the
heirarchy from user functionality rather than the software architecture.
3.) If your menu heirarchy goes more than 3 levels deep, you
need to look seriously at redesigning your menus.
4.) Often used controls should be easily accessible, and preferably
limited to a single function. Don't make the user hunt for the
5.) Controls should be consistent. If buttons are used in different
modes, their operation should be similar (i.e. up/down buttons
shouldn't change to down/up when you enter a different mode).
6.) Follow conventions. If your device has a numeric keypad,
make it look like a telephone keypad. A different layout will
confuse the user and cause them to make errors. Don't be afraid
to *add* a useful function: one of the best designs I ever saw
for a digital clock had a 'back' button, so if you overshot your
time when setting the clock, you didn't have to cycle through
24 hours to get it.
7.) Feedback is important. A click when a key is pressed or highlighing
a menu selection makes all the difference in user confidence.
The more *useful* information that the user has, the more comfortable
they will be using the device (useless information would be something
like having a voice say "a key has been pressed" every time a
key is pressed). If your design will be handheld/portable, add
tactile features (bumps on buttons, clicks on rotary controls,
etc.) to make it easier to operate without having to look at the
unit. Consider that someone will be operating your device while
8.) Just because your device *can* have a feature doesn't mean
it *should* have that feature.
Providing canned options for your device is a sound principle,
but not at the expense of versatility. Recognize that some of
the users of your device will be power users, and will want/need
to fiddle with your available options. Give them a method to do
this, or your competitors will.
I have to agree with you, though-- the best way to get a design
that your end-users will like is to listen to the end-user and
design to their needs.
Don Vollrath writes:
Read your Interfacing the User article in
Jan '02 issue of ESP...Right ON! Too many features = Too much
training required to use it = Too many chances of screwing it
The problem with embedded software is that
it IS complicated. Making special software for every possible
purpose is not feasible. The reason is as you propose...No one
in Marketing is willing (or knows how) to limit the scope or say
'do it this way' with any assurance that that is what the customer
wants. And they don't take the time to find out. So we end up
with bits and pieces of some-else's version of a function glued
into yet-another application, with yet another way to select what
you want it to do. The overall operating system, like ms-windows,
ends up having countless numbers of possible combinations in an
attempt to let everyone please themselves. I can't find the help
I need in the 'Help' file to learn how to get some application
programs to remember where I keep my data files. The basic needs
are lost in the forest of possibilities. Your example of the automobile
radio with many feature pushbuttons is perfect. I don't change
the station and drive on the freeway at the same time because
I can't find the right button by feel.
Defining the needs and desires of the end
user is important - early in the product design process.
Table top discussions and demo I/O scenarios
are good tools to work with. So when my wall phone w/ memory says
'Batt' on the display, does it mean that it is using the battery?
or that the battery is OK? or that the battery needs to be replaced?
The instruction book is about as clear as mud. The correct answer
Keep up the good work,
I would like to thank
you for your article "Interfacing the User". As a biomedical engineer
with several years of working with medical equipment end users,
the frustrations of a too complex user interface and the occaisional
negative effect on patient care is frustrating, to say the least.
Recently, one of our
hospitals (US Veterans Hospital system), reported to me that they
had a 'close call' with a quadraplegic patient on a ventilator.
The nurse had come in to the room flipped the switch just below
'Power' on the panel to turn on the ventilator, and left to check
on her next patient. Unfortunately, that button actually switched
the device to an external battery, which the vent did not have.
Consequently, the patient
was unable to breath and required resuscitation. Luckily, he fully
recovered, but it was too close. When the hospital's Risk Manager
investigated with the head of Respiratory Therapy, the the head
of RT made the same mistake!
My suggestion is to
make medical device controls simple, intuitive and obvious (OK,
all controls). Controls that don't influence the most common functions
of the device should not be mixed in with those that do. A little
thing like moving the internal/external button away from the 'power
label' would prevent this type of thing from happening.
Well, enough dumping.
Again, thanks for your article.
Paul Sherman Biomedical
VA Center for Engineering & Occupational Safety and Health
I just read your article
"Interfacing the user". It was interesting. While reading it,
my reflection was that designers are guessing what the end user
wants. It seems as if the designers neither get requirements nor
talk to customers. It may also be so that usability requirements
are never documented because they are difficult to formulate and
often untestable. These problems may also arise from the hierarcic
structure of companies. Designers are kept away from customers.
It is the project managers that meet. They are more worried about
time plans, than anything else. Being a tester, I have seen a
lot of embroidery that certainly does not come from requirements.
So I guess that those must be blamed on happy designers.
you are right about
the designers not meeting the customers. I have written about
that exact problem. See http://www.panelsoft.com/articles.htm,
"What does the customer really want?".
Here, here - another
instance of using Microsoft as a bad example would be my own favorite
rule, "similar operations in different modules should be performed
in similar ways." For example, even though the Office suite is
supposed to be an integrated software package, the setup for each
one is slightly different. Setting up the default directory is
sometimes an easy option to find (Word), sometimes difficult (getting
Outlook to change the location of the "Personal Folders" directory,
and sometimes impossible (Outlook attachments, Project, Notepad).
Clay Olmstead Applications