---
title: How do I get users to leave feedback about my app?
description: Learn how to collect more app feedback by asking at the right moment, reducing friction and writing prompts that encourage honest responses.
image: https://weareaffective.com/hubfs/learning-centre-images/how-do-i-get-users-to-leave-feedback-about-my-app.webp
---

[Skip to content](https://weareaffective.com/learning-centre/how-do-i-get-users-to-leave-feedback-about-my-app#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

# How do I get users to leave feedback about my app?

 Table of Contents

Feedback is strange. Users who bother to tell you what they think are doing something they have no obligation to do, and yet the typical in-app feedback prompt treats the whole exchange as a minor administrative task. A star rating prompt appears at the wrong moment. A survey link sits buried in a settings menu. A pop-up interrupts the exact thing a user was trying to accomplish. And then product teams wonder why response rates are low, or why the feedback that does come back skews so negative.

> The moment of asking matters as much as what you ask.

The problem is rarely that users do not care. Most people form [opinions about the apps they use](https://weareaffective.com/app-user-research) within the [first few sessions](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one). They notice what works and what does not. They have thoughts. The problem is that the moment of asking, the framing of the question, and the effort required to respond are almost always designed with the product's convenience in mind rather than the user's. Getting feedback at scale means designing the experience of giving it with the same care you give to everything else in the product.

This article covers how to think about feedback design from the ground up, from timing and framing through to placement, friction, and what you do once responses start coming in. The principles draw on behavioural psychology and on work we have done across apps in fitness, travel, and wellness, where the gap between a well-designed feedback prompt and a poorly designed one shows up clearly in the data.

## Why users who give feedback are already doing you a favour

Nobody opens an app thinking they will spend three minutes filling in a survey. Feedback takes time and attention, and the user gets nothing tangible in return. So anyone who does respond is already extending goodwill, and that goodwill is easy to burn through if the experience of giving feedback feels careless or extractive.

The framing of a feedback request matters enormously here. Users who feel they are being asked to do something for the company are far less likely to engage than users who feel they are contributing something useful. On a travel app project we worked on, the original prompt asked users to "rate your experience, " which psychologically reads as a request that serves the company. We reframed the copy to "what would you tell other travellers about this?" and response rates improved noticeably. Users felt they were helping other people rather than providing a corporate metric, even though the information captured was effectively the same.

That shift is not cosmetic. It changes the emotional context in which a user decides whether to engage. Feedback design works best when it is built around what the user gains from the exchange, even if that gain is something as simple as feeling heard, or feeling useful to a community they identify with.

Frame feedback requests around contribution rather than evaluation. "What would you tell someone considering this?" lands very differently to "Rate us out of five."

## When to ask: timing the request around genuine value moments

Timing a feedback request badly is one of the fastest ways to damage both response rates and the quality of what you receive. Historically, mobile apps surfaced rating prompts at the moment a user uninstalled. By that point, the person either had no use for the product anymore or had already had a bad experience. The feedback collected at that moment was structurally skewed negative and told product teams almost nothing about their satisfied users.

The same logic applies to prompts that appear the moment a user opens an app. A client we worked with had added a rating prompt that appeared on launch. The problem is direct: a [user who has just opened the app](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) has not yet done anything. They have no experience to report on. Whatever rating they give is essentially random, and a poor rating from a user who had a bad experience last session gets the same weight as a five-star rating from someone who tapped the button without thinking.

The right moment to ask is after a user has achieved something, completed a workout, booked a trip, logged a habit for a week in a row. People asked at that point are on an emotional high, and they are far more willing to pause and respond. The feedback is also more accurate because it reflects a genuine, recent experience rather than a general impression.

Map your feedback prompts to specific completion events in the user journey. A request that fires after a milestone lands in a completely different emotional state than one that fires on a timer.

## UX/UI design built around *real* psychology

We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package.

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

No commitment

## How long will this take? Setting expectations before users commit

One of the most reliable ways to reduce abandonment mid-feedback is to tell users upfront how long the process takes. This sounds obvious, but the majority of in-app feedback flows do not do it. Users encounter a prompt, tap through to the first question, and then face what feels like an unknown commitment. At any point the next screen could be the last or the start of twelve more, and that uncertainty is enough to make people stop.

We saw this clearly on a fitness app project. The app needed users to complete orientation questions before the [experience could be personalised](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). Drop-off during that section was high. One of the changes we made was simple: we told users at the start how long the questions would take. Nothing technical, just a single line of copy that set an expectation. Users entered the process in a more prepared state and abandonment fell. The content of the questions did not change. The framing around them did.

The same principle applies directly to feedback flows. "This takes about 90 seconds" or "three quick questions" removes the open-ended uncertainty that makes people hesitate. It also signals respect for the user's time, which is itself a [small trust signal that improves engagement](https://weareaffective.com/learning-centre/what-makes-users-trust-a-product-enough-to-enter-their-card-details).

> Telling users how long something takes is one of the lowest-effort, highest-return changes a product team can make.

Accuracy matters here too. If you say 90 seconds and the flow takes four minutes, users feel misled, and that feeling sticks. Measure the actual time across real sessions before committing to the copy.

## What you ask determines what you get: reframing the feedback prompt

The wording of a feedback prompt has a direct effect on both whether people respond and what they say when they do. A question like "How would you rate this app?" invites a number and not much else. A question like "What's working well for you in the app?" invites a different kind of thinking and tends to surface more actionable content.

Open-ended questions with no right or wrong answer let the conversation go somewhere useful. Closed rating scales tell you how satisfied someone is but rarely tell you why, which makes the data hard to act on. A combination of both tends to work well: a quick quantitative signal followed by a single open field that asks the user to say more if they want to. The open field should be genuinely optional. Making it required adds friction and reduces overall completion.

#### Insider bias in question design

One thing worth watching in feedback design is whether the questions assume too much existing knowledge. People who build products find their own products intuitive because they already understand the logic behind them. Questions that use internal language or assume familiarity with features that a newer user might not have found yet will produce feedback that reflects your most engaged users, not your average ones. Separating feedback by user tenure or usage depth before drawing conclusions helps avoid this.

#### Weighting what you receive

Not every response carries equal weight, and treating all feedback as equivalent is a common mistake. Before drawing conclusions from a feedback round, it is worth understanding who responded: their usage patterns, how long they have been in the app, which features they actually use. Feedback from a power user who spends an hour a day in the product tells you something different from feedback from someone who opened the app twice.

## Removing friction from the feedback moment itself

Even a well-timed, well-framed feedback request will fail if the act of responding is cumbersome. Every additional tap, every required field, every redirect to an external survey tool adds friction that some percentage of users will not push through. Reducing that friction is straightforward in principle and consistently underestimated in practice.

On a surveying app we worked on for performance coaches, the original plan required audience members to download a native app in order to participate in live surveys. We pushed back on this. For what was essentially a simple touchpoint, a full app download created too high a barrier. We proposed a QR code approach instead: the presenter creates the survey in the native app, a QR code appears on screen, and audience members scan it and land immediately on a fully branded, mobile-responsive web page. No download, no account creation, no friction. Survey completion rates increased significantly. The experience felt as polished as the native app without the cost of getting there.

The same principle applies to in-app feedback. If you can capture what you need in one or two taps without leaving the current screen, do that. If you need richer data, a short dedicated flow is fine, but keep it within the app wherever possible. Redirecting to an external URL introduces a break in context that reduces completion.

Audit your current feedback flow by counting every tap required from the prompt to the submission confirmation. Each one is a potential exit point.

## Where to place feedback touchpoints across the user journey

Feedback design tends to get treated as a single event, one prompt placed somewhere in the app, rather than as a system of touchpoints distributed across the user journey. A single prompt placed well will collect some data. A set of touchpoints mapped to different stages of the journey will tell you something about how [user sentiment changes over time](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl) and where the drop-offs and high points actually sit.

The table below maps common journey stages to the type of feedback that fits each one.

| Journey stage | User state | Feedback type that fits |
| --- | --- | --- |
| Onboarding completion | Relieved, oriented | "Was that clear?" single-question pulse |
| First value moment | Positive, engaged | Star rating with optional open comment |
| Repeated use (week 2+) | Habitual, forming opinions | Short NPS or open-ended question |
| Feature completion | Task-satisfied | Feature-specific rating |
| Post-support contact | Variable, needs resolution | Resolution satisfaction, single question |

Support requests and help inquiries are themselves a form of feedback, and tracking the common themes in what users ask about can point directly to specific points of confusion in the product. If three support tickets in a week all mention the same screen, that screen has a problem worth investigating, even if none of those users filled in a survey.

## How to respond to feedback so users know they were heard

Feedback gets collected and nothing visible is done with it. Users who took the time to respond have no indication that anything changed as a result, which makes them less likely to respond the next time. Closing the loop, even partially, changes this dynamic.

Closing the loop does not require acting on every piece of feedback. It requires acknowledging that feedback was received and, where possible, showing that it had an effect. A brief in-app message that says "you told us the log screen was hard to find, so we moved it" does several things at once. It tells the user their response was read. It demonstrates that the product improves based on input. And it makes future feedback requests feel more worthwhile because the user has evidence the exchange is real.

#### Permission and ownership in the feedback relationship

Asking permission rather than issuing instructions shifts the psychological dynamic of the whole feedback relationship. Instead of "please complete this survey, " a prompt framed as "would it be okay to ask you a couple of questions about your experience?" gives the user a sense of control. They are opting in, not being directed. That framing makes the exchange feel more like a conversation and less like an obligation, and people who feel they chose to participate tend to give more considered responses.

#### What to do when feedback is negative

Negative feedback handled well can recover a user relationship that would otherwise be lost. If someone reports a problem and receives a personal response that acknowledges the specific issue, that user is often more loyal afterwards than a user who never had a problem. The response does not need to promise a fix on a specific date. It needs to show that a person read what was written and took it seriously.

## Measuring whether your feedback design is actually working

Feedback design can itself be designed and measured, and treating it as a fixed element of the product rather than something that can be tested and improved is a missed opportunity. A few specific metrics will tell you whether what you have built is doing its job.

Response rate is the obvious starting point. [Delighted](https://delighted.com/blog/average-survey-response-rate) put average survey response rates at 10 to 30 percent depending on channel, timing, and audience, and that range is wide enough to mean almost anything. Your baseline matters more than an industry average. Measure what you get now, make a single change, and measure again.

Completion rate within a feedback flow tells you where people are dropping out. If 60% of users who start a feedback form abandon it on the third question, that question is the problem, not the users. Viewing the flow as a funnel with its own completion data is the same analytical posture you would take with an onboarding flow or a purchase journey.

1. Prompt open rate: how many users see the feedback prompt and engage with it rather than dismissing it.
2. Completion rate: how many users who start the flow reach the submission confirmation.
3. Response quality: whether the open-text responses are specific enough to act on, or vague enough to suggest the question is not working.
4. Sentiment trend: whether average ratings are moving over time, and whether changes to the product correlate with changes in sentiment.
5. Response distribution: whether feedback is coming from a representative spread of users or clustering around one type.

Weighting responses by user profile before drawing conclusions is a step that rarely happens. A batch of feedback that looks broadly positive might tell a different story once you separate responses from users who have been in the app for three months from users who joined last week. The two groups are evaluating different things.

## Conclusion

Getting users to leave feedback is a design problem. The timing, the framing, the effort required, the sense of whether a response will matter: all of these are design decisions that shape how many people respond and what they say when they do. Treating the feedback prompt as an afterthought, something placed at the end of the sprint when everything else is done, produces the thin, skewed, barely useful feedback that product teams complain about.

What we have covered here is a different approach: map the feedback touchpoints to real moments in the user journey, tell people how long it will take, frame the request in a way that feels useful rather than extractive, and remove every tap that does not need to be there. Then close the loop, however briefly, so users know the exchange was real. And measure the whole system the way you would measure any other product flow.

The travel app reframe, from "rate your experience" to "what would you tell other travellers, " worked because it changed the emotional context of the request. The fitness app improvement worked because it removed uncertainty at the start of a process. The surveying app QR code approach worked because it removed a barrier that was never necessary. In each case the underlying insight was the same: users respond when the experience of responding is designed with them in mind.

If you want to look at how your current feedback design is working, or build something from scratch that actually collects the data you need, [let's talk about your feedback design](https://weareaffective.com/get-started).

## Frequently Asked Questions

When is the best time to ask users for feedback?

The best time to ask is immediately after a user has experienced genuine value, such as completing a goal or finishing a key task. Asking too early, like the moment someone opens the app, or too late, like when they are uninstalling, means you capture skewed or incomplete responses.

Why are my feedback response rates so low?

Low response rates are usually a sign that the request is timed badly, framed poorly, or placed somewhere inconvenient for the user. If the prompt interrupts what someone is trying to do, or feels like it serves the company rather than the user, most people will simply ignore it.

How should I frame a feedback request to get better responses?

Frame the request around contribution rather than evaluation. Asking 'what would you tell someone considering this app?' tends to perform better than 'rate us out of five', because users feel they are helping others rather than providing a corporate metric.

Does the wording of a feedback prompt really make a difference?

Yes, the wording changes the emotional context in which a user decides whether to respond. Copy that feels extractive or impersonal will put people off, while copy that feels purposeful and community-oriented encourages engagement.

Where should I place a feedback prompt within my app?

Avoid burying feedback links in settings menus, where very few users will ever look. Prompts work best when they appear naturally within the flow of the app, at a moment when the user is already in a positive or reflective state.

Why does feedback from my app skew so negative?

Negative skew often happens because prompts are triggered at the wrong moment, typically when something has gone wrong or when a user is leaving the app. Satisfied users rarely seek out a feedback form on their own, so you need to ask them at the right time to capture a balanced picture.

How much effort should I expect users to put into giving feedback?

You should assume users will give very little effort unless the experience of responding feels easy and worthwhile. Reducing friction, keeping questions short, and making the user feel genuinely heard will all improve both the quantity and quality of responses.

What should I do once feedback starts coming in?

Feedback needs to be reviewed and acted upon regularly, otherwise collecting it becomes pointless. Users who sense that their input is ignored are unlikely to respond again, so closing the loop, even in small ways, is an important part of sustaining a healthy feedback culture.

## 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.