Communications - February 2011

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.

Readers’ comments

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 technical issues.

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
graphics designers.

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:// www.foruse.com/articles/whatusers.htm or other articles in http://www.foruse.com/ publications/ index.htm.

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 disposable prototype.

—Juan Lanus

JAson HonG
“this issue of
design is a
fundamental
problem that
industry doesn’t
quite know
how to get its
head around.”

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.

—Johnny Lee
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.