A one day workshop to practice bringing user or customer insights--ones we glean through observing our own experience--all the way through the design process. Includes notes from a conversation about barriers to implementing this approach in a variety of workplaces.

1. Customer Insight-Driven Design
Welcome

2. What’s today
about?
Doing Customer Insight-
Driven Design.
Seeing what we can learn.

3. What are the steps?
image: Stanford d.school

4. Today’s Design
Challenge
Z-Cycle wants to know:
“How might we use mobile tools
to support our customers‘
biking experience?”

5. Go immerse
Don’t judge. Just observe.
Question everything.
Be truly curious.
Listen. Really.
words: Stanford d.school

6. Interview someone
from another group
Don’t judge. Listen.
Question everything.
Be truly curious.
words: Stanford d.school

7. Map out your
findings

8. Ideate
What if...?

9. Prototype, rapidly
and test.
Don’t guess. Prototype & test.

10. Getting better
feedback
Tell your tester who they are and
what they are doing.
Don’t explain. Don’t defend. Just
listen.
Ask “why?”
For interface feedback, “show
me” not “what do you think?”

11. Today’s Bonus
Design Challenge
Z-Cycle wants to know:
“How might we we bring greater
joy to Boulder using the Z-Cycle
network?”

12. Bringing it into your
own work.
Could you incorporate more
immersion & user empathy
ideation
rapid prototyping
feedback and iteration
into your own work?

13. Concerns
• convey the value of prototyping earlier
• product manager who doesn’t get the importance of user insight
• how to get out of tactical & up to strategy level / time
• how does the research piece function w/in agencies, corporations, how to
convey the value, esp as a standalone without design
• documentation is required, gets in the way of rapid iterations
• fear that if we fail we impact the credibility of the journalism (stakeholders
have more of the fear)
• current process/culture doesn’t involve UX/ why is there a need change
• highly technical, don’t truly understand what we’re designing
• schedule & resources, access to users
• engineering, technology culture, not involved til later in the process,
everyone has a little info so they think they are all set
• fear of ownership/making a decision,
CONFIDENTIAL FOR INTERNAL USE ONLY

14. Overcome
• get devs, etc to share a time they tried hard, released something to the
world, found it wasn’t well received (how did that feel? what was the
business impact?)
• speaking to qualitative data the same way your audience is used to hearing
about quant data (using customer journey map, for example) drawings,
diagrams, graphs, charts
• outsource the grunt work
• guerrilla testing, just do it
• education
• just try getting people to sketch in a requirements mtg (or standard part of
the process)...start small
• put sketches in the requirements document
• hallway testing “this is what I think I heard”
• understand where the fear is come from--is it budget, is it failure, is it
schedule
CONFIDENTIAL FOR INTERNAL USE ONLY

15. Overcome
• quantify, “avert calls to the call center” tie it back to biz value/ROI
• make a very clear business objective, be clear about the metric that matters
(it changes over time)
• make product managers responsible for UX/user satisfaction/user
acceptance
• get others to sketch & test
• get devs to come to usability/observe feedback of sketches, hear it from
someone else
• co-creation with multiple roles
• no lorem
• sketch then quickly to higher fidelity, less wireframing
• make a friend in procurement (keep contract loosely about end result, not
about deliverables)
CONFIDENTIAL FOR INTERNAL USE ONLY

16. Want more?
IDEO
Stanford d.school
Tom Chi, Google Glass

17. Thank you. #designinaday