How to talk to your users

How to talk to your users

Droidcon Turin 2016
#droidconIT

E59595853b7c88a88b0300bdcc226302?s=128

Alex Florescu

April 06, 2016
Tweet

Transcript

  1. HOW TO TALK TO YOUR USERS DROIDCON TURIN 2016 Alex

    Florescu
 @flor3scu YPlan
  2. None
  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. None
  17. EXAMPLE!

  18. 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
  19. DOES IT SOUND LIKE A GOOD IDEA?

  20. WOULD YOU WANT IT?

  21. WOULD YOU PAY FOR IT?

  22. HOW MUCH WOULD YOU PAY FOR IT?

  23. 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?
  24. EXAMPLE #2

  25. RIVER BUS APP ▸ River buses come every 20ish minutes

    ▸ Schedule is a big table ▸ This app tells you when the next ones departs
  26. WOULD YOU WANT AN APP FOR READING THE SCHEDULE?

  27. WOULD YOU WANT TO KNOW WHEN THE NEXT BUS COMES?

  28. WOULD YOU WANT TO GET SERVICE UPDATES?

  29. None
  30. WHAT’S WRONG? ▸ Leading questions ▸ No commitment required ▸

    No risk to user ▸ Personal involvement ▸ Selling, not learning
  31. WHAT’S WRONG? ▸ Problem & solution together ▸ The questions

    assume people care & need ▸ People wrongly report their habits ▸ Personal bias
  32. HOW DO WE FIX THIS?

  33. FIRST RULE

  34. 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
  35. 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
  36. DISCOVER THE USER ▸ Learn the user’s habits that are

    relevant ▸ Create a portrait of the user ▸ The person matters
  37. 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
  38. ▸ 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
  39. 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?
  40. 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
  41. ▸ 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
  42. 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
  43. DISCOVER THE SOLUTION ▸ Do you keep track of how

    much coffee you drink? ▸ If yes, how? ▸ If no, why? EXAMPLE
  44. ▸ 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
  45. 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”
  46. ▸ “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
  47. 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
  48. 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?
  49. 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
  50. MAKING SENSE OF RESULTS ▸ Patterns will form ▸ If

    not, problem or target are too general ▸ Look both at the big picture and the details
 

  51. FIND TARGET ▸ Correlations will highlight certain users groups ▸

    The “profiling” questions allow you to “know” them
  52. EXAMPLE ▸ Big picture: most people don’t track coffee consumption

    ▸ Details: people that do track it also track calories
  53. EXAMPLE #2 ▸ Big picture: people need an easy way

    of looking at the schedule ▸ Details: some people always seem to miss the bus
  54. RINSE & REPEAT ▸ Refine problem, solution & target ▸

    Redo with similar and new questions
  55. HOW DO YOU REACH USERS? ▸ In-app surveys ▸ Email

    surveys ▸ Street surveys ▸ In-person user workshops
  56. 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
  57. 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
  58. 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
  59. READING “The Mom Test” — Rob Fitzpatrick (@robfitz)

  60. THANK YOU Alex Florescu
 @flor3scu Slides: http://bit.do/droidconIT