you want to know when new interviews go online,
subscribe to the WebWord.com
About the Elements of User Experience
with Jesse James Garrett (Author of The
Elements of User Experience)
John S. Rhodes asks: What is user experience and what
does it mean exactly? How does it fit into usability, interaction design,
user center design, and so forth?
experience" simply refers to the way a product behaves and is used in
the real world. A positive user experience is one in which the goals of
both the user and the organization that created the product are met.
"Usability" is one attribute of a successful user experience,
but usability alone does not make an experience positive for the
user. Historically, product design and development has considered
the mere existence of a particular feature as evidence that a user goal is
fulfilled by the product -- with no attention paid to the experience the
user has with the product while using the feature.
This is how we
ended up with VCR clocks that no one can program. It all made sense to the
engineers who put the product together, and it allowed management to check
off "programmable clock" as a user need that had been met, but
nobody thought to examine the problem from the perspective of the
real-world use of the product. This bias toward internal thinking is why
the method by which successful user experiences are created became known
as "user-centered design". Previously, all we had was
"engineering-centered design". Now we've got interaction design,
information architecture, and other sub-disciplines to address the entire
Daniel asks: "user experience" is often only used to
describe user interactions with web sites. How can the term "user
experience" be applied to other *business* and *interface* scenarios?
What positive future implications does this have on the
"usability" consulting field?
"user experience" certainly can be applied to a wide range of
scenarios far beyond the Web. It's likely that we'll see the field of Web
user experience gradually dovetail with practices in fields like
industrial design (creating the user experience of a physical product) and
environment design (creating the user experience of a physical space).
We'll have a lot to contribute to that dialogue, but we'll have a lot to
learn from these other disciplines as well. It won't happen overnight,
though -- ten years seems like the shortest possible time it could
Peter asks: Could you briefly describe your ideal UX development
process, and what roles would you consider important?
to my mind means "infinite time and money", which of course
never really happens. But if I had that luxury, I'd want to spend a lot of
time right up front understanding the problem we're trying to solve:
understanding the business objectives, understanding the behavior and
thinking of the users, understanding the competition. Then the usual stuff
to get to launch: architecture, wireframes, design treatments. After that,
rapid iteration: constantly refining the site in response to targeted
inquiry into what aspects of the experience need work. Specific roles
don't matter so much, as long as your team has the right combination of
skills and experience to pull off the above.
Gustavo asks: How do you draw the line between the design of
elements that are very obvious and clear to your target user and elements
that may confuse him? Of course, provided that you don't have the
money/time to do extensive user testing.
I guess another
way to phrase this question would be: How can you know what will be
familiar or confusing to people if you don't have the opportunity to ask
them? I try to immerse myself in the world of information and interaction
the user inhabits by figuring out what other information sources or
software interfaces the user is accustomed to. For example, if you're
designing for a narrow audience of professionals, are there trade
publications you can turn to for insights into what will be familiar to
those users? Are there other sites they are likely to have seen that deal
with similar content or functionality? Getting inside your user's head
often means trying to see the world through their eyes.
Bryan asks: What efforts do you recommend to enhance the design
or organization of actual content, the words or help that appear on
screen, in order to enhance overall user experience? It is often the most
torturous part of site development, time consuming, fraught with marketing
tension and politics, and yet the ultimate thing that users are intended
to find/read/use as part of their task completion is a site's on-screen
I absolutely agree
that content is sorely neglected in most user experience development
processes. As I've said before elsewhere,
effective communication is central to our work, and nobody -- not even
design school graduates, much as they claim otherwise -- nobody knows more
about communicating effectively than content people. Get your content
experts involved in the process early and often, even if it's an
application project with allegedly minimal content requirements. The final
user experience will be better for it.
Rotwang asks: Amazon's editorial reviews page for your book
includes kind comments from Alan Cooper, Steve Krug, and Louis Rosenfeld.
In what capacity do you know these gentlemen?
I've never met
Alan Cooper. I asked my publisher to send him an advance copy, and he
kindly agreed to share his reaction. Steve Krug and I cross paths at
conferences a couple of times a year. Louis Rosenfeld and I are both
involved in the ongoing activities of the Asilomar
Institute, so naturally I hear from him pretty regularly.
Lydia asks: Imagine a scenario where both schedule and budget is
tight, but you can choose one of the following options: user test with a
large group on core features, or user test with a small group on
everything. Which would you choose and why?
I'd go with
testing the small group on everything. The small group because diminishing
returns set in pretty rapidly with user testing -- by the time you get to
about the eighth user, you're getting very little new insight from each
session. And everything because that will help you identify the problem
areas to explore deeper the next time you come up with a little money for
Zef asks: I would be interested to hear of your experiences in
dealing with cross-cultural websites and any solutions you've come up with
(keeping in mind that we often don't have the luxury of expensive
multi-templated websites catering for every language and culture!).
Here's the point
where I shake my fist at John for encouraging hard questions. Bridging
cultural divides is definitely a hard question. It's important to remember
that you're not the only one facing this problem. Doing a thorough
analysis of approaches taken by competing sites or simply other sites who
have to accommodate the same audiences can help you understand what makes
a particular solution effective. In addition, remember that you're not
just limited to the Web -- other media such as magazines, radio, or
television may offer alternatives you hadn't considered.
JEH asks: You keep saying several times in your book that we
should not "leave any aspect of the user experience to chance".
After seeing the response on SIGIA-L, do you wish you had qualified this
Not at all. There
is not a single user experience practitioner in the world who gets paid to
leave things to chance. I'm not talking about robbing users of their
freedom of choice; I'm talking about making sure that whatever the users
experience as the result of the choices they make is a product of our
conscious, explicit intent. That's the entire purpose of this field.
JEH asks: From what you say about tabs it seems like you don't
like them that much since you mention them under the heading of
"design by mimicry". Do you find that they are often used where
they do not work, or are they just boring because they are overused?
Design by mimicry
happens in many different ways, and I needed an example people could
relate to without a lot of explanation. Tabs are an easy target, because
there was a time (around, say, 1999) when they were widely abused. Steve
Krug and Jeffrey Veen both covered the topic of when tabs work and why
pretty thoroughly in their most recent books.
JEH asks: Since the idea for the book started with the diagram,
it can be seen as a "concept book", and those often fail. How do
you feel that it worked out? Did it end up like you expected?
I think I wrote
the book I set out to write. I think it may not quite be the book some
other people expected me to write, but I've tried to be very clear from
the beginning about exactly what I was trying to accomplish. At one point,
shortly after the book was finished, I went back to look at my original
proposal, which I hadn't seen in about a year and a half. I was pleased
(and a bit surprised) to discover that the description I wrote when the
book was still just an idea pretty closely matched the final
JEH asks: Printing in two colors really does wonders for the
book. How much more expensive is it than one color? At which point in the
writing process was it decided to do the book in two colors?
I don't know how
expensive two-color printing is. I can tell you that it made producing the
illustrations a complicated business. I had originally planned to do the
book in full color -- and in fact, many of the illustrations were
conceived with four-color printing in mind -- but four-color printing
would have made the book more expensive than I wanted it to be.
JEH asks: After reading the book the thought strikes me that
this is a book that should be read by the people who are not likely to
read it. It is a high level book that should be read by the people who
make decisions because it's recommendations concern so many people in an
organization, but it is likely to be read by people like me on the bottom
of the hierarchy with no power to implement much of the recommendations.
Do you agree?
My hope is that
it's the sort of book that can percolate up through the organization. As
insightful and valuable as a book like the polar bear book is, I think few
people would feel comfortable recommending it to their bosses, and fewer
still of those bosses would bother to crack the cover. I wanted my book to
have a fighting chance at being read by the people who really need to hear
what I have to say.
JEH asks: The one thing that the diagram did for me was to help
define the words Information architect, information design, interaction
design, and so on. It was a really wonderful in the that cleared up
confusion without being too specific like you would have had to be if you
had written it down and not made the drawing. But people don't seem to
remember your definition. Right now information architecture seems to
include everything and the kitchen sink. * holding up
"blueprints" and "practical information architecture"
as examples * It at least reaches far into the strategy plane and the
scope plane. Instead of "the user experience" people seem to be
talking about "information architecture" all the way because
"user experience" is not as good a buzzword probably. Is this an
example of worse is better, or will your terminology prevail in a the
I don't think this
is a case of worse is better -- worse here is definitely worse. Narrowly
defined terms are absolutely necessary for us to be able to talk
meaningfully about our work. Any member of any established professional
discipline will tell you the same thing. There is surely a deep irony in a
community that claims professional expertise in developing controlled
vocabularies being so reckless with its own terminology.
hair-splitting has gone beyond merely being a waste of time and is now
actively hindering the progress of our field. It's very disheartening,
because there are lots of interesting aspects of information architecture
to talk about, but nobody seems ready to discuss them because they're
still grappling with definitions. For my part, I've been using the
definitions and the framework in the Elements diagram for close to three
years now, and not once have I felt that they were insufficient for my
Jen asks: What is your advice for selling the process to
clients? Do you have an effective way to convince clients that the 5
planes are a successful model for site development?
I recently wrote
for New Architect on precisely this topic. When it comes down to it,
these arguments are always about money and time. You can, and should, talk
about the quality of the final product, but I think you always have to
frame that discussion in terms of time and money.
Matthew asks: What approaches have you taken when addressing the
issue of multiple audiences needing similar content which would ideally be
presented slightly differently to each audience? What factors influenced
your decisions when making compromises?
these are always made relative to the strategic objectives of the site.
It's very rare that two audiences with conflicting needs are absolutely
equal in strategic priority. Of course, internal politics inevitably come
into play, as stakeholders advocate for their user constituencies, but
that's really as it should be. I don't want to be the one deciding which
audience gets the short end of the content stick, but I do want to make
sure that decision gets made.
Important Note: All
content originally posted on WebWord by respective owners.
Don't miss Jesse's web site: