Ships in the Night (Part II):
Research Without Design?
Steve Portigal
Portigal Consulting | steve@portigal.com
July + August 2009
interactions
In Part I (“Design Without
Research?” interactions May +
June, p. 68) we looked at some
different approaches to design
that do or do not succeed by
omitting research. Here, we
examine some of the limitations of doing research without
design.
A startup approached us just
before it began manufacturing
and asked us to do a last-minute
check with target customers to
verify that it was going in the
right direction. The company
was developing an iPod accessory that would provide protection and allow connections to a
range of other devices. Not until
the kickoff meeting was I able to
see what our participants would
be evaluating: a raw, unfinished
model made of thin plastic,
painted a flat gray. There was a
visible gap between the various
pieces, and it squeaked when
the parts moved. It contained no
electronics, so it weighed only
a few ounces; in short, it was a
far cry from what the startup
intended to manufacture.
Not surprisingly, when people
looked at it next to their glossy
iPods, they were unimpressed.
It wasn’t attractive, it gave no
appearance of sturdiness (
especially when the pieces separated
as I handed it to them!) and no
amount of reassurance—“the
final won’t look like this” and
“the actual product will be made
of sturdier plastic”—was successfully persuasive. We even
brought in renderings of the
final design, showing the level
of finish, but once participants
had held this development artifact in their hands, this aspect
of the design was impossible to
discuss seriously.
The research was far from
worthless; it was effective in
surfacing issues around the possible role of the device. Seeing
this rough prototype (although
our client corrected me in one
user session by explaining that
in fact this was an “appearance
model,” not a prototype) led
people to question just what this
thing was and why they would
want it. Indeed, our client had
articulated only a specification, not a use case, and the
reactions pointed clearly to
the work that we needed to do:
come up with the story for this
product. While we were able to
gain some usability feedback,
we were mostly testing the
design and implementation of
the prototype, not the product.
It was a good lesson learned,
and fortunately, we were able to
identify the most important (if
previously unasked) question:
What is this thing, and why do
I want one? As of this writing,
the client is trying to license its
product out to another manufacturer, so we await the final
answer to that question.
Our client had the right
idea—get feedback on something unfinished in order to
improve the finished product.
Unfortunately, aspects of the
object were so unfinished that
people were unable to make the
leap from the prototype (excuse
me, appearance model) to the
real thing, and the outcomes
shifted away from usability and
aesthetics toward high-level
concept validation. Given that,
there’s always the opportunity
to create something specifically to provoke people around
the deeper issues we want to
explore. Imagine a mobile phone
that is the size of your thumbnail; while not easily manufacturable or usable, as a concept
intended to gather a reaction, it
can be remarkably effective. In
this engagement, we might have
chosen different prototypes to
better explore the questions our
client was trying to address.
Another client approached
us last year with an interesting challenge: It had developed
a set of alternative designs for
an installer application, and the
company wanted to understand
which one was easier to use.
Additionally, in order to appropriately allocate development
resources, the client wanted us
to identify some measure of how
much easier to use one was over
another. We quickly negotiated
a methodology, a budget, and a
Photograph by Jacob Barss-Bailey
