How to talk to your users

Droidcon Turin 2016
#droidconIT

Transcript

1. HOW TO TALK TO YOUR USERS DROIDCON TURIN 2016 Alex Florescu
 @flor3scu YPlan
3. HOW…
4. HOW…
5. ▸ do we build X? ▸ do we solve problem Y? ▸ do we architect/test/design? HOW…
6. HOW…
7. WHAT & WHY
8. WHAT & WHY ▸ What features do we build ▸ What features do we remove ▸ What apps do we work on ▸ Why is this feature/bug important
9. WHAT & WHY ▸ What do users care about? ▸ Why do users care about this?
10. NOT TECHNICAL NO CODE
11. 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
12. WHY?
13. NOT MY PROBLEM?
14. 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
15. WHAT QUESTIONS DO YOU ASK?
16. …
18. EXAMPLE!
19. 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
20. DOES IT SOUND LIKE A GOOD IDEA?
21. WOULD YOU WANT IT?
22. WOULD YOU PAY FOR IT?
23. HOW MUCH WOULD YOU PAY FOR IT?
24. 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?
25. EXAMPLE #2
26. RIVER BUS APP ▸ River buses come every 20ish minutes ▸ Schedule is a big table ▸ This app tells you when the next ones departs
27. WOULD YOU WANT AN APP FOR READING THE SCHEDULE?
28. WOULD YOU WANT TO KNOW WHEN THE NEXT BUS COMES?
29. WOULD YOU WANT TO GET SERVICE UPDATES?
31. WHAT’S WRONG? ▸ Leading questions ▸ No commitment required ▸ No risk to user ▸ Personal involvement ▸ Selling, not learning
32. WHAT’S WRONG? ▸ Problem & solution together ▸ The questions assume people care & need ▸ People wrongly report their habits ▸ Personal bias
33. HOW DO WE FIX THIS?
34. FIRST RULE
35. 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
36. 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
37. DISCOVER THE USER ▸ Learn the user’s habits that are relevant ▸ Create a portrait of the user ▸ The person matters
38. 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
39. ▸ 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
40. 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?
41. 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
42. ▸ 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
43. 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
44. DISCOVER THE SOLUTION ▸ Do you keep track of how much coffee you drink? ▸ If yes, how? ▸ If no, why? EXAMPLE
45. ▸ How do you check the time of the next river bus? ▸ Where do you find the schedule? ▸ How do you make sure you get to work on time? DISCOVER THE SOLUTION EXAMPLE #2
46. BE SPECIFIC ▸ Start general if needed, but dig into specifics ▸ Understand core problems and needs, rather than “feature requests” ▸ Say “go on”, “tell me more” and “why”
47. ▸ “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
48. 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
49. 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 fix/improve it? ▸ How much time does it eat up? ▸ What are your priorities/goals/big problems?
50. 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
51. MAKING SENSE OF RESULTS ▸ Patterns will form ▸ If not, problem or target are too general ▸ Look both at the big picture and the details
 

52. FIND TARGET ▸ Correlations will highlight certain users groups ▸ The “profiling” questions allow you to “know” them
53. EXAMPLE ▸ Big picture: most people don’t track coffee consumption ▸ Details: people that do track it also track calories
54. EXAMPLE #2 ▸ Big picture: people need an easy way of looking at the schedule ▸ Details: some people always seem to miss the bus
55. RINSE & REPEAT ▸ Refine problem, solution & target ▸ Redo with similar and new questions
56. HOW DO YOU REACH USERS? ▸ In-app surveys ▸ Email surveys ▸ Street surveys ▸ In-person user workshops
57. 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
58. 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 difficult to A/B test 
 (e.g. chat, social features etc.) ▸ Some features require a lot of upfront work
59. 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
60. READING “The Mom Test” — Rob Fitzpatrick (@robfitz)
61. THANK YOU Alex Florescu
 @flor3scu Slides: http://bit.do/droidconIT