Are there any unbreakble laws for interaction designers?
Just one. Design for the users.
How did you come up with Tesler's Law of the Conservation of
Complexity?
In the early days of our field, when I worked at
Xerox PARC, the idea of user interface consistency was new and
controversial. Many of us realized that consistency would benefit
not only users, but also developers, because standards could be
encapsulated in shared software libraries. We made an economic
argument: If we establish standards and encourage consistency,
we can reduce time to market and code size.
In 1983-85, when I was developing
the MacApp object-oriented framework at Apple, I advocated a
three-layer code model. In addition
to the Macintosh Toolbox--a shared software library--and the application
itself, I made the case for an intermediate layer that implemented
what I called a "generic application". A generic application was
a real interactive program--with windows, menus, and commands--that
did nothing at all, but did it in a standard way. You could create,
open, save and print documents, but the documents lacked form and
were empty of content. You built your actual application by modifying
the generic application in an object-oriented way.
To sell the idea to Apple management and independent
software vendors, I came up with the Law of Conservation of Complexity.
I postulated that every application must have an inherent amount
of irreducible complexity. The only question is who will have to
deal with it.
Because computers back then were small, slow and
expensive, programs were designed to be compact, not easy to use.
The user had to deal with complexity because the programmer couldn't.
But commercial software is written once and used millions of times.
If a million users each waste a minute a day dealing with complexity
that an engineer could have eliminated in a week by making the
software a little more complex, you are penalizing the user to
make the engineer's job easier.
Whose time is more important to the success of your
business? For mass market software, unless you have a sustainable
monopoly position, the customer's time has to be more important
to you than your own.
The idea of the object-oriented framework, developed
at PARC by Trygve Reenskaug, and the idea of the generic application,
which I developed with my MacApp team, made investment in ease
of use more palatable to developers by making it cheaper to reduce
complexity than to increase it. The further down in the software
hierarchy that you push the complexity, the less work has to be
done by everybody above. MacApp's promise was, if you make life
easier for our mutual customers, we'll make development easier
for you.
What are the most common mistakes that beginning interaction
designers make?
What mistakes beginners make varies a lot, partly
based on their background and training.
Some educators, particularly in computer science
departments, tell their students to design for themselves as the
users. If taken literally, that advice leads to interfaces that
only computer science students can use.
I do believe that if you learn
to place yourself in the shoes of the user, you can design "for yourself" and really
be designing for the user. I call this approach "Method Design" because
the mind set is similar to that of Stanislavsky's "method acting".
You're really not designing for yourself at all. You're designing
for "your character". Of course, to be a successful Method Designer,
you need to know your character. That's one reason designers should
observe ethnographic studies and usability studies.
Beginners often succumb to pressure
from management to "save money" by skipping usability tests despite
serious open questions. At the other extreme, beginners sometimes
run many more
tests than necessary, bring in too many subjects, spend too much
time preparing formal reports, or fail to pick their battles.
Usability testing should always be done before a
designer finalizes unproven or controversial interface elements.
But testing should be conducted in the cheapest possible way.
Of course, it is sometimes necessary to demonstrate
the value of research to skeptics. In that case, it is worth taking
a couple of hours to edit a highlight video showing the severity
of the users' confusion.
Two other mistakes made more by beginners than experienced
designers are to ignore standards and to follow standards unthinkingly.
Consistency is usually good, so you need a really good reason to
diverge from standards. But you can not be sure you have a really
good reason unless you actually see your users do much better with
the custom design element than with the standard.
Choice of words is important.
Shorter is usually better. But if you have to explain what "x" means to many of your
users--or worse, to your teammates--then you should probably replace "x" by
whatever you said to explain it.
To my mind, what most separates an expert from a
beginning designer is the ability to draw from a larger space of
potential solutions. Given a particular problem, the beginner and
the expert may at first think of the same solution, say, a multi-page
flow with numerous forms. But the beginner is likely to fixate
on the solution even if it is inordinately complicated. The senior
designer will consider radical alternatives, say, a way for the
user to see the data as it would look in its final state and edit
it in place.
The senior designer won't stop simplifying until
the design is simple enough. It need not take months to go through
this simplification process. It can take just days, or hours, even
seconds. Great design often takes time, but it's wasteful to spend
time on approaches that are not simple enough to have a chance
of being final.
|
