In this guide
You asked testers to find bugs and got a wish list: dark mode, export, widgets, a calendar view, sharing. It is a good sign that people care, but a list of ideas is not a plan. If you build everything, the app grows in every direction and none of it is finished. Sort first, then choose.
Step 1: Sort every item into one of four boxes
| Box | Question | Example |
|---|---|---|
| Bug | Does the app do something other than it was meant to? | Save button does nothing |
| Usability issue | Does it work, but people get lost or slow? | Cannot find where to edit an entry |
| Wish | Is it something new that does not exist yet? | "Add an export to CSV" |
| Opinion | Is it taste, with no task behind it? | "I prefer blue" |
Bugs and usability issues belong in your normal fix process. Opinions go in a note unless several people say the same thing. The rest of this page is about wishes.
Step 2: Turn each wish into a problem
A wish is a solution someone invented. Under it sits a task they could not finish. Ask: "What were you trying to do?" Then write the problem in one sentence.
| Wish | Problem to solve |
|---|---|
| "Add export to CSV" | "I need to get my data into a spreadsheet for my accountant" |
| "Add widgets" | "I want to see today's status without opening the app" |
| "Calendar view" | "I cannot see what is coming up over the next weeks" |
Now you can ask whether a smaller or cheaper solution exists. A weekly email may solve the calendar problem faster than a new screen.
Step 3: Count and group
- Merge similar problems into one line.
- Add a mark for each independent person who raised it.
- Put the ones that match your app's main purpose at the top.
Ten different ideas often reduce to three problems. Treat the problems as the list, not the ideas.
Step 4: Apply simple rules
- Does it serve the core task? If your app is a timer, a budgeting chart is not part of the core.
- Do several independent people raise the same problem? One request is a signal to watch, three is a signal to act.
- Is it cheap and safe? Small and low-risk wishes can go in early; large ones need a decision.
- Does it add upkeep? Every feature must be maintained, tested and explained.
- Does it fit your target user? Not every tester is your user.
Anything that fails the first rule goes in a "not now" list. That is a decision, not a rejection.
Step 5: Tell the testers
Reply with what you decided: "Planned for the next update", "Thinking about it", or "Not now, because it doesn't fit the focus". People accept "no" better than silence. Do not promise dates you cannot keep.
Keep requests from flooding in
- Give testers a task for the test, so they report on that and not on everything.
- Provide a separate place for ideas. One field for problems and one for wishes keeps the two apart.
- Say in the invitation what stage the app is at, for example "I only want to know about bugs and confusing parts now".
For a general ranking by impact and effort, see how to prioritize app feedback.
Related
- Overview: App testing problems and fixes
- How to get crash logs from a tester's phone
- Bugs that only appear in one language or region
AppReviewX gives you private, structured feedback, which helps keep bugs, usability and wishes apart. One feedback you write earns one credit. Start free