UC Berkeley School of Information | firstname.lastname@example.org
Elizabeth Goodman is a Ph.D. candidate at UC Berkeley’s School
of Information. Her dissertation research focuses on commercial
interaction design practice and ubiquitous computing.
How I Learned to Stop Worrying
and Love the Deliverable
the implementations of their ideas
require communication in drawing,
writing, and verbal presentation.
All three skills are required
because the usual interaction design
deliverables, such as wireframes
and site maps, are flawed. As static
documents, they cannot themselves
fully demonstrate the digital interactions that designers want to communicate. But they have become the
expected—and required—end result
in many workplaces.
Luckily, in everyday interaction
design, the deliverable doesn’t have
September + October 2012
I don’t remember when I first heard
the word deliverable, but I do remember ferociously loathing it.
Many of interactions’ readers
undoubtedly live and breathe deliverables, but here’s a quick definition
for those who are still innocent: A
deliverable is a document created
by one group of people that is then
passed to another. Hence the name.
Like a parcel, a deliverable has a
sender and a receiver. In commercial interaction design, the sender is
likely a designer or consultant; the
receiver, the developer or client. As
a primary form of communication
between key players in the creation
of a technological product, deliverables can have very high stakes.
As a print graphic designer, I
never heard the word. I dealt with
comps, flats, or proofs. I started
hearing requests for deliverables
only when I started working as an
I didn’t like it at all.
To be honest, my dislike was
instinctive rather than intellectual. Hearing or saying
deliverable reminded me that my work
depended on other people. That
instead of holding the fate of my
ideas in my own hands, I had to give
up control to other people. That my
personal visions were just technical specifications. The word
deliverable symbolized what I saw as the
standardization of creativity into
prosaic routines. It just seemed so…
industrial. Like working on a digital
I had gone into interaction design
because I loved imagining new digital things—useful, playful, provocative, exciting things. But I didn’t see
myself as a member of an industry,
or even of a team. And therein lay
the problem: I saw myself as an
inventor of things, rather than a
maker of products.
Flash forward to about three
The word deliverable had long
since stopped irritating me. In fact,
I took it for granted. By the time I
started my dissertation research, an
observational study of interaction
design work in consultancies, I used
the word almost every day without
much noticing it.
However, in observing interaction
design projects over the past three
years, I have entirely changed my
mind. As a word, deliverable is neither irritating nor unremarkable. I
now see it as wonderfully precise—a
perfect description, in fact, for how
interaction designers work, the
skills they cultivate, and some current troubles they face.
Let me explain.
As professionals, interaction
designers rarely have to write pro-duction-ready code. Some may not
ever touch code at all. They produce
diagrams and text as design specifications that they deliver to others.
Organizational distance between
the makers of specifications and the
makers of working code means that
interaction designers don’t have final
control over what’s made. Instead,