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
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
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
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 ▸ 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 ▸ 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
▸ 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
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”
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 fix/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
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 difficult to A/B test (e.g. chat, social features etc.) ▸ Some features require a lot of upfront work
anothem
assu_ming
codehex
bells17
ojun9
koic
clown0082
blueswen
techouse
texmeijin
ivargrimstad
ykws
aridlehoover
eileencodes
mza
colly
62gerente
myddelton
jacobian
kevinliebholz
danielanewman
chriscoyier
lara
destraynor
smashingmag