In-App User Surveys: 9 Questions to Improve Your App Experience

I once watched someone use an app I’d helped build and… they stared at the screen like it had personally offended them. Not angry. Just confused. Thumb hovering. Tiny sigh. Then they did the thing every app owner hates: they closed it and went back to whatever they were doing before.

We’d been patting ourselves on the back because “engagement” looked fine. Sessions were up. The charts were politely pointing north. But in that moment, sitting next to a real human, I realised how easy it is to miss the obvious stuff when you’re living inside your own product.

This is where in-app user surveys earn their keep. Not the big annual “tell us everything” questionnaire that nobody finishes. I mean small, well-timed questions that show up while someone’s actually using your app—when the memory is fresh and the friction is real.

If you’re building an app for your business (or trying to improve one that already exists), here are nine questions I keep coming back to. They’re simple. Almost annoyingly simple. That’s kind of the point.

Why in-app surveys beat “we’ll ask later”

Email surveys are fine if you enjoy low response rates and vague answers like “It’s good” or “It’s confusing” with no context. In-app surveys catch people in the moment—right after they’ve tried to do the thing your app exists for.

It’s not magic. It’s just timing. When someone has just completed a booking, uploaded a photo, placed an order, or rage-tapped a button that didn’t respond… they’ve got an opinion. Your job is to ask it gently, quickly, and then get out of the way.

Also: people are more honest when they’re not writing an essay. Give them a one-tap rating, a short multiple choice, and a single optional text box. You’ll get more signal with less effort—on both sides.

The nine questions (and when to ask them)

I’m going to give you the questions, but the real secret is when you ask. If you interrupt someone mid-task, you deserve the angry feedback you get. If you ask right after a meaningful moment—completion, failure, or a “huh?”—you’ll learn fast.

1) “What brought you here today?”

This is my favourite early-stage question because it cuts through your assumptions. You think people open your app for Feature A, but half of them are trying to do Feature B… and the other half are just looking for your opening hours.

Ask this on the second or third session, not the first. First session is chaos—people are still orienting. Keep the options short: 4–6 choices max, plus “Something else”.

Best moment: early onboarding, after the user has done one meaningful action
Why it helps: clarifies user intent so you can improve navigation and prioritise features

2) “Were you able to do what you came to do?” (Yes/No)

This one looks almost stupid. It’s not. It’s a blunt instrument that tells you whether your app is delivering on its promise.

If they say “No”, follow up with one line: “What stopped you?” Don’t force an essay—just an optional text field. You’re looking for patterns, not poetry.

Best moment: after a session ends, or after a key flow (checkout, booking, upload)
Why it helps: connects intent to outcome—your most important gap

3) “How easy was that?” (1–5)

People will tolerate a lot if they’re getting value. But they won’t tolerate feeling stupid. This question helps you spot where “it works” still feels like a slog.

Ask it after a specific action, not randomly. “How easy was that?” right after “Add a new invoice” is useful. “How easy is our app?” is basically a fortune cookie.

Best moment: right after a key task completion
Why it helps: pinpoints friction while the memory is fresh

4) “What nearly made you give up?”

This one feels a bit cheeky, which is why it works. You’re giving people permission to admit they struggled without making them feel like they failed.

You’ll get answers like “I couldn’t find the button” or “I didn’t trust the payment screen” or “It asked me to create an account and I just… didn’t want to.” Those are gold.

Best moment: after a long session, or after a user repeats an action (a sign they’re stuck)
Why it helps: surfaces near-churn moments you won’t see in analytics

5) “Which part felt unclear?”

If you only ask open-ended questions, you’ll drown in messy answers. If you only ask multiple choice, you’ll miss the weird edge cases. This question is a nice middle ground.

Offer a short list based on the flow: “Pricing”, “Delivery”, “Permissions”, “Connecting your account”, “Something else”. Then—again—optional text if they want to elaborate.

Best moment: after a help-centre visit, or after a user backs out of a screen
Why it helps: tells you what to rewrite, redesign, or explain better

6) “What’s missing?”

This is the dangerous one, because users will ask for everything. Dark mode. A calendar. A chatbot. A feature that already exists but they didn’t find (which is its own kind of feedback, really).

Still worth asking—just don’t treat it like a roadmap vote. Look for repeated themes and underlying needs: “I need to share this with my team” is more important than “Add a share button”.

Best moment: after the user has reached “aha” and used the app a few times
Why it helps: reveals unmet needs and opportunities for retention

7) “How would you feel if you couldn’t use this app tomorrow?”

This is a classic (the “Sean Ellis test”), and yes, it’s a bit dramatic. But it gets at something important: are you a nice-to-have or a must-have?

Use options like: “Very disappointed”, “Somewhat disappointed”, “Not disappointed”, “I no longer use it”. If you’re early, don’t panic if the numbers aren’t pretty. Just be honest about what they’re telling you.

Best moment: after 2–4 weeks of usage, or after a user hits a milestone
Why it helps: measures product-market pull without pretending you’ve ‘arrived’

8) “What’s the one thing we should improve first?”

If you ask “Any feedback?” you’ll get a shrug. If you ask for one thing, you force prioritisation. People actually like being asked to choose.

And you’ll notice something: the most valuable answers are often boring. “Make it faster.” “Stop logging me out.” “Remember my last selection.” Not glamorous. Extremely profitable.

Best moment: after a user leaves a rating, or after several sessions
Why it helps: gives you a practical, user-led priority list

9) “Can you tell us why?” (only after a rating)

If you’re collecting app ratings or NPS-style scores, the number alone is basically trivia. The “why” is where the work is.

But here’s the catch: don’t ask everyone for a written explanation. Ask it conditionally. If someone gives a low score, ask what went wrong. If someone gives a high score, ask what they value most. Different question, different insight.

Best moment: immediately after a 1–5 rating or NPS question
Why it helps: turns a vague score into an actionable fix (or a message you can lean into)

A few practical rules so your surveys don’t annoy people

I’ve seen in-app surveys done so badly they become a reason to uninstall. Which is… impressive, in a dark way. So, a few guardrails.

Keep it short. One question is a survey. Two questions is pushing it. Three questions is you getting greedy. If you need more, spread it across time.

Be weirdly polite about timing. Don’t pop a survey the second someone opens the app. Let them do the thing. Then ask. And if they dismiss it, don’t chase them around the interface like a lost puppy.

Target the right users. New users can tell you what’s confusing. Power users can tell you what’s missing. People who just failed a payment can tell you what’s broken. Don’t ask everyone the same thing and then act surprised when the answers conflict.

Close the loop quietly. You don’t need a big announcement. But a small release note—“Improved checkout speed” or “Made the upload button easier to find”—does two things: it tells users you’re listening, and it tells your team the feedback isn’t going into a black hole.

What you’ll notice when you start doing this

The first thing you’ll notice is how often users blame themselves. “Maybe I’m just being thick,” they’ll write, right before describing a design problem you’ve been ignoring for months. It’s humbling. Also useful.

The second thing: the best feedback is specific, and it tends to arrive in small, repeatable phrases. “I couldn’t find…” “I expected…” “I didn’t trust…” When you see the same sentence five times, you’ve got a job to do.

And the third thing—this one surprised me early on—is that a good in-app user survey doesn’t just collect feedback. It changes the relationship. It makes the app feel less like a vending machine and more like a place where someone’s paying attention.

Not in a creepy way. Just in a human way.

Because most people don’t want to rant. They want the app to work, they want to feel competent using it, and they want to get on with their day. If your in-app surveys help you give them that… you’ll feel it in the numbers, sure.

But you’ll also feel it in that tiny moment when someone doesn’t sigh and close the app. They just… keep going.