Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
How to talk to your users
April 06, 2016
How to talk to your users
Droidcon Turin 2016
April 06, 2016
More Decks by Alex Florescu
See All by Alex Florescu
Other Decks in Programming
See All in Programming
See All Featured
HOW TO TALK TO YOUR USERS DROIDCON TURIN 2016 Alex
Florescu @ﬂor3scu YPlan
▸ do we build X? ▸ do we solve problem
Y? ▸ do we architect/test/design? HOW…
WHAT & WHY
WHAT & WHY ▸ What features do we build ▸
What features do we remove ▸ What apps do we work on ▸ Why is this feature/bug important
WHAT & WHY ▸ What do users care about? ▸
Why do users care about this?
NOT TECHNICAL NO CODE
POINTS ▸ How do you ask your users about new
features ▸ No magic wand, just methods & principles ▸ How do we ask questions ▸ What are the right and wrong questions
NOT MY PROBLEM?
WHAT & WHY MATTER! ▸ Avoid useless features ▸ Avoid
building apps that never get downloaded ▸ Avoid building solutions in search for problems ▸ Understand the user needs ▸ Be part of the conversation
WHAT QUESTIONS DO YOU ASK?
COFFEE TRACKING APP ▸ Uses magical new technology to precisely
track your caffeine intake ▸ You can see just how much coffee you had ▸ Patterns of caffeine spike/drop
DOES IT SOUND LIKE A GOOD IDEA?
WOULD YOU WANT IT?
WOULD YOU PAY FOR IT?
HOW MUCH WOULD YOU PAY FOR IT?
FEATURE QUESTIONS ▸ Would you want to set a caffeine
limit? ▸ How do you want to track your drinks? ▸ What graphs would you want to see?
RIVER BUS APP ▸ River buses come every 20ish minutes
▸ Schedule is a big table ▸ This app tells you when the next ones departs
WOULD YOU WANT AN APP FOR READING THE SCHEDULE?
WOULD YOU WANT TO KNOW WHEN THE NEXT BUS COMES?
WOULD YOU WANT TO GET SERVICE UPDATES?
WHAT’S WRONG? ▸ Leading questions ▸ No commitment required ▸
No risk to user ▸ Personal involvement ▸ Selling, not learning
WHAT’S WRONG? ▸ Problem & solution together ▸ The questions
assume people care & need ▸ People wrongly report their habits ▸ Personal bias
HOW DO WE FIX THIS?
RULE #1 ▸ Don’t mention the app / new feature
/ idea ▸ Don’t describe what you’re building ▸ Don’t even say you’re building something NEVER MENTION THE APP
NEVER MENTION THE PROBLEM ▸ Don’t mention the problem you’re
trying to solve ▸ Don’t describe what you think are the issues ▸ Don’t say you’re building a solution RULE #2
DISCOVER THE USER ▸ Learn the user’s habits that are
relevant ▸ Create a portrait of the user ▸ The person matters
DISCOVER THE USER ▸ Do you drink coffee? How many
coffees a day? ▸ What coffee do you like? ▸ Do you track calories? ▸ What was the last app you used today? EXAMPLE
▸ How do you commute to work? ▸ How do
you go around on weekends? ▸ How do you kill time on your commute? ▸ Are you a morning person? DISCOVER THE USER EXAMPLE #2
DISCOVER THE PROBLEM ▸ Test your assumptions about the problem
▸ Try to determine how people perceive it ▸ How big of a problem is it? How painful?
DISCOVER THE PROBLEM ▸ Do you worry about drinking too
much coffee? ▸ Do you have trouble sleeping? ▸ Has your doctor asked you to limit caffeine? EXAMPLE
▸ How long do you usually wait for a river
bus? ▸ What do you do when you wait? ▸ Do you know what time your usual service is? ▸ When did you last narrowly miss a bus? DISCOVER THE PROBLEM EXAMPLE #2
DISCOVER THE SOLUTION ▸ Work your way towards your solution
▸ Start with the problem and let the users describe the solution to you ▸ If you’re right, you will hear your solution ▸ If you’re not, you get valuable insight
DISCOVER THE SOLUTION ▸ Do you keep track of how
much coffee you drink? ▸ If yes, how? ▸ If no, why? EXAMPLE
▸ How do you check the time of the next
river bus? ▸ Where do you ﬁnd the schedule? ▸ How do you make sure you get to work on time? DISCOVER THE SOLUTION EXAMPLE #2
BE SPECIFIC ▸ Start general if needed, but dig into
speciﬁcs ▸ Understand core problems and needs, rather than “feature requests” ▸ Say “go on”, “tell me more” and “why”
▸ “I would love to track my coffee consumption” ▸
Why? ▸ “Yeah, I am worried about drinking too much” ▸ Tell me more. Why is that? BE SPECIFIC EXAMPLE
EXAMPLE #2 ▸ “I need to know about service disruptions”
▸ Why? How do you use that information? ▸ “I want realtime schedule updates” ▸ Go on. How does that help? BE SPECIFIC
ASK THE KEY QUESTIONS ▸ How do you deal with
it today? ▸ Why is it a problem? What makes it so bad? ▸ What are you already trying to ﬁx/improve it? ▸ How much time does it eat up? ▸ What are your priorities/goals/big problems?
BE OBJECTIVE ▸ It may be hard to be objective
about the results ▸ Uninvolved people will be the most objective ▸ Believe the story your survey tells you
MAKING SENSE OF RESULTS ▸ Patterns will form ▸ If
not, problem or target are too general ▸ Look both at the big picture and the details
FIND TARGET ▸ Correlations will highlight certain users groups ▸
The “proﬁling” questions allow you to “know” them
EXAMPLE ▸ Big picture: most people don’t track coffee consumption
▸ Details: people that do track it also track calories
EXAMPLE #2 ▸ Big picture: people need an easy way
of looking at the schedule ▸ Details: some people always seem to miss the bus
RINSE & REPEAT ▸ Reﬁne problem, solution & target ▸
Redo with similar and new questions
HOW DO YOU REACH USERS? ▸ In-app surveys ▸ Email
surveys ▸ Street surveys ▸ In-person user workshops
TALKING TO USERS IS CHEAP! ▸ Building things is very
expensive ▸ Building the wrong thing can be disastrous ▸ Talking to users is, comparatively, almost free ▸ It is also perfectly safe
DON’T A/B TESTS SOLVE THIS? ▸ A/B tests still require
you build “something” ▸ You build based on assumption ▸ Not applicable to brand new projects ▸ Some features are difﬁcult to A/B test (e.g. chat, social features etc.) ▸ Some features require a lot of upfront work
SUMMARY ▸ Discover, don’t sell ▸ Do this early, do
it often ▸ Everyone’s job to get what & why right ▸ Doesn’t replace UX workshops or AB tests
READING “The Mom Test” — Rob Fitzpatrick (@robﬁtz)
THANK YOU Alex Florescu @ﬂor3scu Slides: http://bit.do/droidconIT