Design is Good For
Dan Saffer, Kicker Studio
Dilemma: Most of the
products we use,
including many we
love, weren’t made
using UCD techniques.
There are five major
Approaches = Ways
to Answer Questions
When we have to make a design decision in the middle of a project (or even when ﬁrst
deciding the product strategy), how do we go about making that decision?
Focus on User Needs and GOALS. Designer is translator of user needs and goals. Users guide
the product decisions.
Focus is on the tasks and activities that need to be accomplished. Users are the performers of
activities. Role of the designer is to provide tools to accomplish actions.
Focus is on watching which provided option is preferred. Users are sources of behavioral
data. Designers are creators of options.
Focus is on the components of the system: sensor, comparator, actuator. Users set the goals
of the system. Designers make sure all the parts are in place.
Focus is on the skill and wisdom of the designer. Users are a source of validation (often via
usability testing). Designer is the source of inspiration.
Genius Design Most
Of course, in practice, we’re constantly weaving between the different approaches.
The Dirty Little Secret
All of these methods rely on the skill of the designer in one way or another.
No matter how many
users you talk to, no
matter how much data
you collect, at the end
of the day, a human
has to decide.
User Input + Designer
Input can come AFTER the product is out, of course. And that input can be disastrous.
No amount of data
analysis can make up
for a lack of talent.
Takes the talent of the designer to determine what the results of a UCD process should be.
Users (and their data)
should be there to
inform designers, not
substitute for them.
The purpose of UCD should be to bolster, enlighten, or conﬁrm designer’s judgement.
Many people suggest that "you guys
should optimize the UI to match the
feature usage data." ...The only
problem? We've already designed that
product, and it's called Office 2003.
Jensen Harris on Office 2007
Research can be wrong.
The conclusions you can
draw from research can
Just as one example, with small sample sizes (which is usually what you’re working with with
UCD), you can prove just about anything.
Blue cars get hit by rocks more often than other cars, therefore we should never paint our
approaches work better
for different problems
than for others.
• Good for intense, focused, complex activities
• Reﬁning task ﬂows
• Making actions more efﬁcient
• Not good for big picture rethinking
• Can de-skill users
• Good for existing designs
• Incremental improvements
• Fine tuning of a design
• Not good at all for big picture rethinking
• Mind numbingly tedious
• Can end up with a real dog’s breakfast
• Good for large-scale designs
• Systems of Systems
• Models for large teams
• Not good for small projects
• Very analytical
• Good for rapid projects
• Possible to get a “purer” vision and more
radical jumps in products
• Not good for inexperienced designers
• Need domain knowledge
• Can be very, very wrong
• Understand unfamiliar domains
• Empathy with users—focus on people
• Can catch problems (and opportunities) up front
• Hard for people to evaluate (and generate) new
product ideas—Ford’s “Faster Horse” analogy
• Are you focused on the RIGHT users?
• User goals can be slippery
• Does it scale?
The trick is to determine
what approach works
best for the project
you’re on...even for just
part of the project.
Honest appraisal of your own skills, what’s the problem is (do you understand the users for
Theory: UCD is best for
within an established
Great ideas can’t be
tested. Only mediocre
ideas can be tested.
@odannyboy on Twitter
@kickerstudio on Twitter