Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to talk to your users

How to talk to your users

Droidcon Turin 2016
#droidconIT

Alex Florescu

April 06, 2016
Tweet

More Decks by Alex Florescu

Other Decks in Programming

Transcript

  1. ▸ do we build X? ▸ do we solve problem

    Y? ▸ do we architect/test/design? HOW…
  2. WHAT & WHY ▸ What features do we build ▸

    What features do we remove ▸ What apps do we work on ▸ Why is this feature/bug important
  3. WHAT & WHY ▸ What do users care about? ▸

    Why do users care about this?
  4. 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
  5. 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
  6. 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
  7. 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?
  8. RIVER BUS APP ▸ River buses come every 20ish minutes

    ▸ Schedule is a big table ▸ This app tells you when the next ones departs
  9. WHAT’S WRONG? ▸ Leading questions ▸ No commitment required ▸

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

    assume people care & need ▸ People wrongly report their habits ▸ Personal bias
  11. 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
  12. 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
  13. DISCOVER THE USER ▸ Learn the user’s habits that are

    relevant ▸ Create a portrait of the user ▸ The person matters
  14. 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
  15. ▸ 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
  16. 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?
  17. 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
  18. ▸ 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
  19. 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
  20. DISCOVER THE SOLUTION ▸ Do you keep track of how

    much coffee you drink? ▸ If yes, how? ▸ If no, why? EXAMPLE
  21. ▸ 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
  22. 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”
  23. ▸ “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
  24. 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
  25. 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?
  26. 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
  27. MAKING SENSE OF RESULTS ▸ Patterns will form ▸ If

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

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

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

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

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

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

    surveys ▸ Street surveys ▸ In-person user workshops
  33. 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
  34. 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
  35. 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