zations to make software rather than
just “lipstick on a pig.” The problem
becomes even harder when the system
combines hardware, software, and
services, which describes pretty much
every system we will have in the future.
I want to make clear that we, as researchers and educators, don’t know
the answer either. But, in my next blog
entry, I’ll write about my discussion
with someone who used to work at
Apple, with some insights about how
its process works. I’ll also be visiting
Google next week, so I’ll be sure to ask
them these same questions.
P.S. I want to get your comments
and feedback, but please don’t use the
word “intuitive,” talk about “dumbing
down interfaces,” or say that users are
“dumb, stupid, and naïve.” These are
signals that you really don’t know what
you’re talking about. And, yes, not all
interfaces have to be walk-up-and-use.
On one side we have the “geek culture”
people, oblivious of what happens to the
user, doing self-referential design. On the
other hand, we have the designers with
their MacBooks, reluctant to delve into
Between them there is a void that
supports the “nobody is in charge” stance.
Actually, the void was created before
everything happened, before the software
was written and way before the designers
cringed. The void is, in fact, the lack of a
usable user interface (UI) definition in the
requirements and software design stages.
If it´s not specified then, the outcome might
be anything. For example, the outcome
might be a good UI every now and then, as
it happens nowadays, making you say “a lot
of user interfaces today are just plain bad.”
Functional analysts and software
architects have to raise the flag, not
See, for example, some writings by
Larry Constantine. He got it many years
ago, and he is a geek like Alan Cooper and
Jakob Nielsen. Not a designer. See http://
or other articles in http://www.foruse.com/
The design activity that determines the
usability of a nontrivial UI is the one that
happens before writing the first line of code.
Moreover, before starting to envision a
“this issue of
design is a
how to get its
Many of these observations are
spot on—even uncomfortably accurate.
However, perhaps a missing observation
is that these five different issues are not
independent and many share a similar
root cause. Much of it comes down to
the leadership in the company and the
resulting decision-making processes.
Projects, resources, and timelines are
typically dictated at a very high level,
often by those who exclusively focus on a
multiyear competitive business strategy.
That calculus is generally of the form “To
improve our performance in market X, we
need to create product y, with features Z by
Q2 of next year because our competitors A,
B, C are likely releasing e, F, and G.”
The notion of “good design” ends up
becoming a product “feature” that just like
any other feature has to be scoped and
completed by a particular deadline and
preferably not revisited. Good design is
typically not at the essence of a product’s
reason for existing. More often than not,
projects are green-lit based solely on
whether there is a pressing business
need, rather than on the belief something
genuinely great could or should be created.
This core issue, in my opinion, sets into
place a series of processes, priorities,
and corporate culture that accounts for
nearly all of your observations. Prioritizing
good design requires a culture where
by “creating a great experience” is a
slightly higher priority than “maintaining
a strategically competitive market share.”
It’s a little bit of a “built it and they will
come” mentality—which, understandably,
is not a pill many executives readily
swallow, especially if their compensation is
connected to the stock price.
Occasionally, business needs and good
hw/sw/ux design do happen to align. But
it is fairly rare. A leadership team that can
see past the battlefield of business needs
with enough vision and taste to identify
the seedlings of a great and profitable
experience … is rarer still.
I’d change the question to “Why is great
design so infrequent?” because we have
solved much harder problems. It requires
a leader who needs to enforce the principle
of profitability—i.e., “We are going to design
a product that will outsell our competitors’
products because they will want to buy
it”—and the infrequency of great design is
a result of the infrequency of these leaders.
I suspect they are often only one person
who comes to the project with a picture
of what is needed…. [Y]ou don’t need 50
design engineers; rather, what’s needed is
one responsible “profit” engineer—one who
is willing to delay each step of development
until trial users give their feedback. You
can’t predict what users will want, but you
can put prototypes in their hand and have
them tell you what they want.
Jason Hong responds
One of the goals of emerging human-computer interaction programs is to
cross-train “Renaissance teams” that
can combine the best of design, computer science, and behavioral science.
I take the term “Renaissance team”
from Randy Pausch, who noted that
given the scope of knowledge today,
“Renaissance man” is a near impossibility today. Plus, people tend to listen
to me more when I quote him. :-)
On the computer science side, I’ve
been advocating that all computer science undergrads should be required
to take at least 1) a machine learning
course, and 2) a human-computer interaction course. My rationale is that
these two themes are fundamental to
the future of computer science. Taking
a machine learning course is an easy
sell in CS departments and starting to
happen, but it’s less so with HCI.
I’m not sure yet what to advocate
on the design and behavioral science
side of things, though.
Jason hong is an assistant professor of computer science
at Carnegie Mellon University.
© 2011 ACM 0001-0782/11/0200 $10.00