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:Visual metaphors From:"Jared M. Spool" <jspool -at- UIE -dot- COM> Date:Sun, 10 Mar 1996 20:56:48 -0500
There has been a fair amount of discussion on this list lately about
visual metaphors. We've done quite a bit of usability testing on
this topic. I thought I'd share some of our results.
____________________
Users Don't See Metaphors
We've tested many products that have explicit metaphors. Unless the
users are explicitly told about these metaphors, they almost never
see them.
Also, the metaphors never seem to have any direct impact on whether
a user can succeed at the tasks or not. The user's ability to
figure out the steps a procedure is more impacted on the information
on the screen and their previous experiences.
In Quicken, it might be presumed that the user follows a Check and
Checkbook metaphor. However, users do not perceive from the outset
that Checks in Quicken act like Checks in a checkbook. Nor do they
perceive that the register acts the same way. While users like the
graphic representations, they perform the same without them.
____________________
Metaphors Break
It is extremely easy to "break" a metaphor, such that it works
against the user. There are two ways to do this: First, by having
functionality that is outside of the metaphor and Second, by having
illogical functionality within the metaphor.
In the discussions on this list, someone mentioned the MS Word Page
View versus Normal modes. We've observed that these two modes
confuse users, even experienced users. While Page View is supposed
to follow a paper metaphor, it does so at an extreme. Users have
trouble moving from one page to the next and are surprised by many of
the subtleties, such as how the horizontal arrow keys differ from the
vertical arrow keys.
New users using a desktop metaphor can not explain how it relates to
a desktop. Nor can they predict behaviors of common actions such as
pull-down menu choices, dragging, single clicking and double
clicking. If a metaphor is to make learning easier, it hasn't done
so in these cases.
____________________
Mental Models Rule
Regardless of the metaphor chosen, the user's mental model is what
the developer needs to create. A mental model is a series of
beliefs about how the application behaves. Users have been shown to
develop mental models that allow them to successfully predict
application behavior regardless of the presence of a metaphor.
One of the most used applications in the world, the automatic teller
machine, has few, if any, identifiable metaphoric attributes.
However, before initial use, users can successfully predict the
outcome of most functions.
____________________
Consistency Is A Red Herring
One argument for metaphors is to provide internal consistency.
However, in our work, we have generally found consistency to be a
red herring. It is possible to build a "consistent" application
which is unusable just as it is possible to build an inconsistent
application which users can use flawlessly. As long as the user
understands the clues the interface provides and builds a mental
model that they need, the interface will succeed.
____________________
Designing Mental Models
It is up to the development team (which includes technical
communicators) to design the mental model they want the users to
hold. This includes deciding what information the user needs to know
and what information they don't need.
We often use the example of Walt Disney World's Haunted House. The
developers decided what ghosts, lighting, screams and general
spookiness the guests would experience. If the guests come out of
the ride thinking that the 180 watt surround sound speaker system
really added to the ride, then the ride itself has failed.
In testing a video conferencing system, we found that users would get
messages such as "7 unrecoverable ECC errors." What were they
expected to do with this information? Why was the system telling
them this?
To design a mental model, the developer needs to decide exactly what
the experience of the user will be. This can be easily tested and
evaluated. Those products which do an excellent job of this are the
ones that users find the easiest to use.
The information presented here is based on observations we've made of
hundreds of users working with dozens of products. However, we have
never tested *your* users working with *your* product. Our experience
is that every user uses every product differently, your mileage will
vary.
User Interface Engineering is a consulting firm specializing in
Product Usability issues. Our mission is to empower development teams
by providing key information for making strategic design decisions.
Our services include training, consulting and research.
==========================================================
Jared M. Spool User Interface Engineering
jspool -at- uie -dot- com 800 Turnpike Street, Suite 101
(508) 975-4343 North Andover, MA 01845
fax: (508) 975-5353 USA
If you send me your postal address, you'll get
the next issue of our newsletter, Eye For Design.
==========================================================
