How to collect useful feedback in your mobile app

“The save button doesn't work.”

Imagine finding that message in the feedback for a recipe app you are building. You open a recipe on your phone and tap Save. It works. Now you need to find out what happened on the other person's screen.

Give people a way to send feedback while they are still looking at the problem. Ask what they were trying to do, and keep the screen context with their message. That gives you somewhere to start when a report reaches you.

The recipe app in this article is a hypothetical example. We'll follow one report from the feedback form through to checking a change.

Put feedback within reach

A feedback button belongs somewhere people can find it when they need it. An edge tab can work across several screens. A link in Settings is another option, though someone reporting a problem will have to leave the screen they were using.

Try the route yourself on a phone. Open the keyboard on a busy screen, then see whether you can still reach the feedback button. Go back to the app after closing the form. You should be able to carry on with what you were doing.

Keep the form short enough to use in that moment. A required account or a long questionnaire adds work before the person has even explained the problem. If you need a way to reply, offer an optional contact field and explain how you will use it.

For a specific product question, choose a moment that gives it meaning. A person who has just edited a recipe can tell you which part of editing was awkward. Ask something concrete, such as “Was there anything you wanted to change in this recipe but couldn't?” Let them dismiss the question and continue using the app.

Ask what the person was trying to do

“Any feedback?” leaves a lot for someone to work out. Give the message field a prompt that helps them describe the situation. These questions work together:

• What were you trying to do?
• What happened when you tried?

They can be helper text under a single message field. You can follow up with “What did you expect to happen?” when the answer leaves that unclear.

For our imaginary recipe app, a useful message might read:

I changed the amount of flour and tried to save the recipe. The keyboard was still open. I couldn't reach the Save button at the bottom.

That gives you an action to try. Keep the person's original wording alongside any summary you write. If they say they couldn't reach the button, a summary such as “Save fails” would lose a useful clue.

Feature requests benefit from the same question about intent. If someone asks for a duplicate button, find out what they are trying to duplicate and why. You may learn that they keep making a second copy of a recipe so they can change one ingredient without losing the original.

Keep the screen with the message

In the example, a screenshot could show the keyboard covering the bottom of the form. A screen name would tell you which editor was open. If your app can attach that context, the person reporting the problem has less to describe from memory.

Decide what you need to investigate a report. A useful starting point is:

Context	What it helps you check
Screen and selected element	Where to start looking in the app. Use a name that you can find in the code.
App version	Whether the report came from the build you are testing.
Device and operating system	Which environment to use when trying the same action.
Screenshot	What was visible around the problem when it was reported.

A screenshot only shows one moment. Keep the written message with it so you know what the person did beforehand. Give them a chance to review the image and remove it before sending. Hide sensitive parts of the screen from the capture, then test that behavior with made-up data.

The guides on feedback screenshots in SwiftUI and feedback screenshots in Expo explain how this works in Nitpick. They also cover the limits of capturing a screen.

Work through the report

Set aside a regular time to read incoming feedback. Keep an open report until you have recorded a decision about it. If several reports describe the same behavior, link them to the same issue so you can keep track of the affected versions.

For the recipe example, you could work through the report like this:

1. Write down the behavior to investigate. “Save is covered while editing an ingredient with the keyboard open” is specific enough to test. Keep the screenshot attached to the issue.
2. Try the reported action. Use the reported app version on a matching device or simulator. Open the recipe editor and change an ingredient. Leave the keyboard open when you try to save. Record whether you can reproduce the problem.
3. Choose a change once you understand the cause. In this hypothetical case, you might find that the bottom of the form does not move above the keyboard. Check the layout before deciding how to make Save reachable. If you use a coding agent, give it the original report and ask it to explain what it found before editing.
4. Check the result through the same interaction. Edit the ingredient with the keyboard open and save it. Reopen the recipe to confirm that the new amount was stored. Also try saving with the keyboard closed, so the change is checked in the other state of the form.

If you cannot reproduce a report, record what you tried. Ask a focused follow-up if you have a way to contact the person. “Did this happen after you changed an ingredient?” is easier to answer than a request to explain the whole problem again.

Make a decision about what to fix

Read each report for its effect on the person using the app. A blocked Save button prevents them from keeping their work. A request to move a label has a different effect. Note that impact when you decide what to work on next.

A report from one person can still reveal a serious problem. You can investigate it while keeping the extent of the problem uncertain. Look for the same behavior in other reports, and record which devices you have actually checked.

When you ship a fix, keep the release version with the issue. If a similar message arrives later, compare the versions before assuming the fix failed. Where you have a reply address, tell the person which update contains the change. Only promise a reply if you plan to read and answer those messages.

Try the whole route in your own app

Before asking users for feedback, send a report from your own phone. Describe a specific problem, then open the report wherever you plan to manage it. See whether you can find the affected screen using only what arrived.

Ask someone who has not seen the problem to try the same thing. Note what they have to ask you. That tells you which context or wording your feedback form still needs.

If you want to add Nitpick to your app, start with the SwiftUI setup guide or the Expo setup guide. Once it is in place, run that same test from the user's side of the screen.