customer insight driven design
DESCRIPTION
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.TRANSCRIPT
Welcome
Customer Insight-Driven Design
Doing Customer Insight-Driven Design.
Seeing what we can learn.
What’s today about?
What are the steps?
image: Stanford d.school
Z-Cycle wants to know: “How might we use mobile tools
to support our customers‘ biking experience?”
Today’s Design Challenge
Go immerseDon’t judge. Just observe.
Question everything.Be truly curious.Listen. Really.
words: Stanford d.school
Interview someone from another group
Don’t judge. Listen.Question everything.
Be truly curious.
words: Stanford d.school
Map out your findings
Ideate
What if...?
Don’t guess. Prototype & test.
Prototype, rapidly and test.
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?”
Z-Cycle wants to know: “How might we we bring greater joy to Boulder using the Z-Cycle
network?”
Today’s Bonus Design Challenge
Bringing it into your own work.
Could you incorporate moreimmersion & user empathy
ideationrapid prototyping
feedback and iteration into your own work?
CONFIDENTIAL FOR INTERNAL USE ONLY
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
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
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)
Want more?IDEO
Stanford d.schoolTom Chi, Google Glass
Thank you. #designinaday