---
title: What questions should I ask users when collecting feedback?
description: Learn which questions to ask users when collecting feedback, why most feedback forms mislead you, and how to uncover what users actually think and do.
image: https://weareaffective.com/hubfs/learning-centre-images/what-questions-should-i-ask-users-when-collecting-feedback.webp
---

[Skip to content](https://weareaffective.com/learning-centre/what-questions-should-i-ask-users-when-collecting-feedback#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# What questions should I ask users when collecting feedback?

 Table of Contents

Feedback forms are everywhere, and most of them are asking the wrong things. A wellness brand asks "how satisfied were you with your experience?" A hotel asks "would you recommend us to a friend?" A fitness app asks "how easy was the app to use?" These questions feel thorough. They produce numbers. They fill dashboards. And they rarely tell you anything you can actually build on, because they are designed to confirm what the team already suspects rather than surface what users genuinely think.

> The absence of a good question does not mean the answer is yes.

The problem runs deeper than question wording. It sits in the assumption that users will tell you what matters if you just ask them directly. They often cannot, and a question that invites reassurance over honesty will get reassurance every time. When we worked with a pre-investment client on building out their feedback approach, we found that their investor conversations covered technology, marketing, and market size, but nobody had ever asked users how the product felt to use or what would make them come back. The silence was read as approval. It was not. The absence of a good question does not mean the answer is yes.

What follows is a practical guide to the questions worth asking, the questions worth dropping, and the distinction between the two. The goal is feedback that tells you something you did not already know.

## Questions that confirm versus questions that discover

Most feedback questions are written by people who already believe something about their product. That belief shapes every word. "What did you love about the checkout experience?" assumes there was something to love. "How easy was it to find what you were looking for?" assumes the user was looking for something in a linear way. Even a scale from one to ten carries a hidden assumption, which is that the user's experience can be meaningfully averaged into a number.

Confirming questions are not always wrong. Once you have a hypothesis you need to test, a targeted closed question can tell you whether it holds. The problem is that researchers reach for closed questions before they have done the discovery work. They are measuring something they have not yet defined, and the result is data that feels solid but explains nothing.

Discovering questions work differently. They do not point at a feature or an experience and ask for a verdict. They ask what the user was trying to do, what happened, and how they felt about it. "Walk me through what you did the last time you used the app" is a discovering question. So is "what did you do before this product existed, and how did you feel about that?" The user is telling a story rather than issuing a judgement, and stories carry far more signal than scores.

A useful way to check which kind you are writing is to ask whether you could have guessed the range of answers before the user responded. If yes, it is probably a confirming question.

## What you actually need to learn from users

Before writing any question, it helps to be clear about what you are actually trying to learn. There are four things that genuinely matter in most feedback exercises.

1. What the user was trying to achieve, in their own words
2. Where the current experience fell short of that goal
3. What they did instead when the product did not work for them
4. How they felt at the points where things went wrong

Notice that none of these are questions about features, scores, or satisfaction ratings. They are [questions about behaviour and emotion](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl), which is where the useful information lives. A user who rates your app seven out of ten tells you almost nothing. A user who says "I kept getting halfway through and then losing track of where I was" tells you something you can act on.

The emotional dimension matters as much as the functional one. We ask about how somebody feels doing a process, not just what they are specifically doing. A user who finds a process annoying but completes it anyway is a different signal to a user who finds the same process so frustrating they abandon it. Both might give you a six out of ten, and you would not know which was which.

We also look at what users do between interactions. If someone downloads a fitness app, logs a session, and then [does not return for three weeks](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one), the gap is telling you something. The question is what. And that question cannot be answered by a single survey sent once after sign-up.

## Design that understands *your* users

We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates.

[See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started)

No commitment

## How to ask about problems without leading the witness

Leading questions are the most common source of useless feedback, and they are harder to spot than they look. "Did you find the navigation confusing?" is obviously leading. But "how confusing did you find the navigation?" is just as bad, because it assumes the user found it confusing at all. Even "what did you find confusing about the navigation?" carries the same assumption.

The fix is to remove the assumption from the question entirely. "What happened when you tried to find \[specific thing\]?" gives the user room to say it was fine, to say they got lost, or to say they did not bother trying. All three are useful. A leading question can only confirm or deny the team's existing belief.

This matters more than people expect, because Nielsen Norman Group research found that the framing of an identical result changed whether UX designers called for a redesign: [according to Smashing Magazine's writeup of that research](https://www.smashingmagazine.com/2017/10/avoid-bias-ux-feedback/), 51% of designers who received a negatively framed result wanted a redesign, compared to only 39% who received the same data framed positively. If professional designers are that sensitive to framing, users answering a feedback form are not immune.

The best approach is to ask about a specific moment rather than a general impression. "Tell me what happened the first time you tried to place an order" is a question about a moment. "How was the ordering experience?" is a question about a general impression, and general impressions are reconstructions shaped by whatever happened most recently, not accurate reports of the whole experience.

Remove the assumption before you remove the jargon. A plain question that still leads the user is worse than a slightly awkward question that does not.

## How to ask about behaviour, not opinion

Opinion questions produce opinions, which are rationalised after the fact and often wrong about what actually drives behaviour. A user might tell you they check the app every morning when in reality they open it twice a week. This is the natural gap between how people think they behave and [what they actually do](https://weareaffective.com/learning-centre/how-to-structure-a-behavioural-risk-register-before-you-write-a-single-user-stor).

Behaviour questions do this by asking about specific, recent actions rather than general habits. The difference is between "how often do you use the reorder feature?" and "the last time you reordered something, what did you do?" The second question is grounded in a real event. The first invites the user to construct a self-image and report that instead.

A useful rule is to anchor every question to a specific moment: the last time, the most recent occasion, the first thing they did. This forces both parties to talk about something real.

Behavioural data from the product itself can also do work that survey questions cannot. High dwell time on a particular page, users dropping off at the same step, or the same support question arriving repeatedly are all behavioural signals that deserve as much attention as what users say. When we track support requests and look for common themes, patterns emerge that users would never have flagged directly, because they did not connect their confusion to a design problem. They just thought they were bad at technology.

Ask "what did you do the last time..." rather than "what do you usually do...". One is grounded in fact. The other is a guess dressed as a report.

## When silence in feedback is the real signal

Low response rates, blank comment boxes, and skipped questions are all data. They are easy to dismiss as disengagement, but they often point to something more specific: users who do not feel the question applies to them, users who tried to answer and gave up, or users who have no strong feeling because the product has made no impression at all.

The structure of silence matters. If a specific question is consistently left blank, that question may be too abstract, too personal, or simply unclear. If an entire survey is abandoned halfway through, length is probably the issue. Surveys longer than 12 minutes on desktop, or 9 minutes on mobile, see a notable drop in completion according to [Qualtrics guidance on survey methodology](https://www.qualtrics.com/support/survey-platform/survey-module/survey-checker/survey-methodology-compliance-best-practices), and that drop carries information about which questions users found too effortful to answer.

We have also seen the silence that comes from a product that investors engaged with intellectually but never emotionally. When we worked with a pre-investment client, investor conversations covered all the functional dimensions: technology, marketing, market size. Nobody asked how the product would feel to use. The investors did not raise questions about retention or emotional engagement, and the team read that absence as confidence. We had to go back and address the emotional side explicitly, because the silence had been mistaken for a green light.

Silence in feedback is worth the same attention as a written response. The user who says nothing is telling you something, even if you have to do more work to hear it.

## How to check whether your questions reflect your assumptions

Every feedback question is a theory about what matters. The question "did the new checkout flow feel faster?" embeds the theory that speed is what users care about in checkout. The question "how clear was the product information?" embeds the theory that clarity was a problem. Those theories might be right. But they should be visible rather than hidden inside the question structure.

A practical check is to read each question and ask where it came from. If the answer is "we think users find this confusing" or "we got a complaint about this once", that is a stakeholder assumption, and it carries the risk of what we call insider bias: the team's familiarity with the product shapes what it considers worth asking about, and that shapes what it learns.

People who know a product deeply will find it intuitive because they understand its logic and context. A new user approaching the same product without that prior knowledge may find it completely opaque. Conflating those two perspectives is one of the [most common mistakes in building](https://weareaffective.com/learning-centre/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app) a feedback exercise, and it produces surveys that are very good at confirming what the team already knows and very poor at finding what it does not.

The remedy is to build at least some questions that have no assumed answer. "What was the most confusing part of the process?" assumes there was a confusing part, but not which one. "What would have to change for you to use this more often?" makes no assumption at all and invites the user to set the agenda.

Before sending any survey, ask yourself what you would do if every answer contradicted your expectations. If the honest answer is "probably nothing", the questions are confirmatory, and they will stay that way.

## What to do when the answers contradict what you believed

This is where the real work is done. A feedback process that only surfaces confirmation is a reassurance mechanism. The point of asking questions you do not already know the answer to is that you will sometimes hear something you do not want to hear.

When we ran discovery with a pre-launch founder in the football industry, he arrived with a colour-coded spreadsheet mapping out competitor products, with the goal of merging several of them into one product. He was visibly pleased with what he had built. We started asking questions about prospective users: why would someone choose an all-in-one product over the specialised apps they were already using? Would consolidation make individual features less capable? The founder was deflated by those questions. But being honest about what will make a product succeed is the job. Building on assumptions that survive only because they were never tested serves nobody.

When feedback contradicts a belief, the first step is to check whether the question was sound. A leading question that produced a surprising answer may have produced an artefact of its own structure rather than a real user position. But if the question was clean and the answer still surprises, that is the most valuable thing a feedback exercise can produce.

A structured approach helps here. Review who responded and whether those users are the ones whose feedback carries most weight for the feature under discussion. Map what the feedback means for both business value and user uptake. Then apply honest prioritisation: what does this change about [what gets built next](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-), what gets delayed, and what gets dropped? Feedback that is reviewed but does not change any decision was probably not reviewed at all.

## Conclusion

Good feedback questions are not comfortable. They do not invite the user to confirm that things went well. They ask the user to reconstruct a real moment, describe what they actually did, and say honestly where the experience fell short. That is harder to write, and the answers are harder to sit with. But they are the only answers that tell you something you could not have worked out without asking.

The questions worth asking are grounded in specific moments rather than general impressions, focused on behaviour rather than opinion, and free of the assumptions the team brought into the room. The questions worth dropping are the ones that could only ever confirm what you already believe.

We start by asking what users were trying to do, what happened when they tried, and how they felt about the gap between the two. Everything else follows from that. The tracking, the timing, the structured debrief, the effort-versus-impact decisions: all of it depends on having asked questions good enough to learn from in the first place.

If your current feedback process is producing data that rarely surprises you, the questions are probably the problem. [Let's talk about building a feedback approach that actually tells you something](https://weareaffective.com/get-started).

This article is part of our guide to [App User Research](https://weareaffective.com/app-user-research).

## Frequently Asked Questions

What is wrong with asking users questions like 'how satisfied were you with your experience?'

These questions are designed to confirm what a team already suspects rather than uncover what users genuinely think. They produce numbers that fill dashboards but rarely give you anything you can act on or build from.

What is the difference between a confirming question and a discovering question?

A confirming question points at a feature or experience and asks for a verdict, often assuming the answer before the user responds. A discovering question asks the user to tell a story, covering what they were trying to do, what happened, and how they felt.

How can I tell whether a question I have written is confirming rather than discovering?

Ask yourself whether you could have guessed the range of answers before the user responded. If the answer is yes, you are most likely writing a confirming question rather than a genuinely open one.

Can closed questions ever be useful in feedback research?

Yes, but only once you have already done discovery work and have a clear hypothesis you need to test. The problem arises when researchers reach for closed questions before they have defined what they are actually measuring.

What four things should I be trying to learn from users in a feedback exercise?

You should focus on what the user was trying to achieve in their own words, where the experience fell short of that goal, what they did instead when the product did not work, and how they felt at the points where things went wrong. These focus on behaviour and emotion, which is where the most useful information lives.

Why do users sometimes struggle to tell you what matters when asked directly?

Users often cannot articulate what matters most because they are not used to thinking analytically about their own behaviour in the moment. A question that invites reassurance over honesty will almost always get reassurance, which makes direct questions unreliable for discovery.

Is silence or a lack of complaints from users a good sign that things are working?

No. If you have not asked the right questions, silence simply means you have not surfaced the problems yet. As the article puts it, the absence of a good question does not mean the answer is yes.

Why is a numerical score like seven out of ten not very useful on its own?

A score tells you almost nothing about what drove it or what a user would need to feel differently. Scores assume that a complex experience can be meaningfully averaged into a single number, which strips away the context that makes feedback actionable.

## Related Articles

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.