Effective
Engineering
e-Newsletter
– 12/8/2005
This is your monthly e-Newsletter from
Effective Engineering Consulting Services
(www.effectiveeng.com).
If you would like to receive Effective Engineering e-newsletters as they are
published, please send an email to
e-newsletter@effectiveeng.com, and we
will add you to our distribution list. Comments and suggestions are welcome
and encouraged!
eN-051208:
The Inmates Are Running The Asylum!
[1]
By Tom Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
What do you get when you cross a computer with an
alarm clock? With a camera? With a car? With anything else? The answer,
according to Alan Cooper in his excellent book, “The Inmates Are
Running The Asylum” [1], is that you get a computer!
Alan is an interaction designer, and has observed that, as virtually
everything is being equipped with computer technology, those who develop
these products have often abdicated their responsibility to make these
products easy to use. They may think they’re making their products
easy to use, but they’re really making products that are easy to use
for others like them.
It is the engineers who are designing these products and running the show.
In Alan’s terms, we are letting the inmates run the asylum! The
problem is that engineers are designing products in ways that make it easier
for them to develop, using approaches that make sense to them and others
like them. However, the people who use these products are generally not
engineers, and engineers are different from other people. What makes sense
to engineers often does not make sense to others, and what makes things
easier for engineers to develop products often makes those products more
difficult for non-engineers to understand and use. Furthermore, the fact
that a particular approach makes it easier for engineers to develop products
is generally of no interest to an end user.
End users quite simply do not want to be made to feel stupid, and just want
to be able to use a product easily and intuitively. They would really love
to be delighted with computer-based products, but far too often have to
settle for being able to muddle along with them, to tolerate them, or in
some cases to actively hate them but have no choice but to use them.
This craft of interaction design is new and unfamiliar to software
developers and many others. When programmers do design, they tend to think
of themselves as users, but this does not reflect the reality of their
users. Programmers are often willing to trade simplicity for control, and
success for understanding. They focus on what is possible to the exclusion
of what is probable while everyday users do just the opposite. They develop
software that forgets, making users reconfigure to their workflow every time
it runs. They develop software that doesn’t focus on what the user really
wants it to do. They develop software that doesn’t give the user enough
relevant information, such that when it fails the user has no idea of why it
failed. They develop software that is inflexible and always works the same
way even when humans would adapt the work process in the same situation.
They develop software that doesn’t help its users; when it fails, error
messages should be accurate and helpful to the use but often are not. They
develop software that won’t take responsibility; instead of annoying “are
you sure?” dialog boxes, software should allow for operations to be
undone if the user wasn’t sure.
End users want their products to be easy to interact with. This is the role
of the interaction designer, and their role is distinctly different
from that of the engineer. The key to solving the problem of making
products easy to use is to do the interaction design before the
programming. Interaction designers focus on how products behave,
communicate, or inform. They focus on the way end users see and interact
with software-based products. Interaction designers first think
conceptually, then in terms of behavior, and last in terms of interface. A
really well designed product will create fierce loyalty in customers. It
will create desirability. Desires are not needs; they have an even more
profound effect on people’s behavior than needs. Many of Apple’s products
are strong examples; think iPod, iMac, PowerBook.
The way interaction designers often work is to create personas.
A persona is a precise description of the user and what he/she wishes
to accomplish. It is not a real person, but the persona must be
well-defined and believable as a person. A persona is sufficiently
defined when its needs are clearly unique. The purpose of this is to make
it possible for the designer to design for that persona instead of
for himself, to truly get into the mind of the persona. Multiple
personas are typically created, and after careful review, one primary
persona is identified and that is the persona to be designed
for. Personas end feature debates. A feature might be useful for a
number of users, but if it is not desired by the primary persona,
then it need not be included, or at least should not interfere with the
operations of the primary persona.
Trying to please different user groups who have contradictory needs by
compromising never works; in these cases multiple interfaces should be
designed. Features that are not needed by the primary persona, but
are desirable for other lesser personas may be appropriate to
include, but it may take some effort on the part of that lesser persona
that may not even be evident to the primary persona. Users who
want/need these special capabilities are generally willing to put effort
into getting to these capabilities because they feel it is a fair exchange
for the reward of having the capabilities.
The essence of good interaction design is to devise interactions that
let users achieve their practical goals without violating their personal
goals (i.e. the need not to feel stupid). It is such goals that should be
designed for. By defining persona’s goals, the interaction design
of the persona with the product can be fleshed out and defined. The
primary focus should be on daily-use and necessary-use scenarios.
Necessary-use scenarios are those that the user must be able to do, but are
only done infrequently or under special circumstances. It is the daily-use
interactions that should be as polished as possible. Interfaces can often
be simplified by placing daily-use controls and data prominently and moving
all others to secondary locations, out of sight. Edge case scenarios (rare
use) can be largely ignored in interaction design; they must be
implemented, but should receive little emphasis in the interaction design
phase. No matter how “cool” a user interface is, less of it is almost
always better.
Interaction design teams should not include
programmers or managers; they should have specific training in
interaction design. Such teams should be kept small, with no more than
2-3 designers per product. They should be kept insulated from managers and
programmers while they are researching and designing personas.
There is so much more to be explored in interaction design. This
e-Newsletter barely scratches the surface. The key is that end users want
products that they truly love, but they have been conditioned to expect much
less. If you want to succeed beyond your wildest expectations, you must
design products to absolutely delight your customers. To do this properly
requires a different approach that is not driven by engineering. It must be
driven by designing for the end user. That takes a different approach, to
really concentrate on the interactions end users will have with your product
and make that design truly outstanding.
__________
[1] Alan Cooper, “The Inmates Are Running The Asylum”, Copyright © 2004,
Sams Publishing.
Copyright © 2005
Effective Engineering Consulting
Services, All Rights Reserved
