AI / Design Communication & Image Prompting
Turning User Feedback into a Change List
Extract what to change from a pile of complaints — and what not to act on
Here is the raw user feedback: [paste feedback]. Turn it into a design change list: 1) First merge it into no more than 6 problem categories, each with an occurrence count; 2) Separate what users say from what they actually run into — mark which are wording problems and which are flow problems; 3) Give one change action per item and note whether it changes the UI, the flow, or the copy; 4) Sort by 'people affected × cost of the fix'; 5) List which suggestions should not be followed, and why. Do not treat feedback as requirements, and do not rank something first just because it was said loudly.
How to use
With fewer than 20 pieces of feedback the conclusions are unstable — collect more before doing this step.
Good for
- Feedback has piled up (group chats, tickets, app-store reviews) and you need to decide what this release changes — merge into categories first, then rank by people affected times cost to fix.
- When you need to push back on 'whoever shouts loudest goes first' in a meeting — that takes a list that names what should not be acted on and why.
Not for
- You have fewer than 20 pieces of feedback — the sample is too small for stable categories or ranking; collect more or run interviews instead.
- All the feedback comes from one power user — that is not representative; segment by user type first, or the product becomes a tool for one person.
Example
Input
20 pieces of feedback: 7 say export is too slow, 5 cannot find the export button, 3 ask for bulk delete, 2 say the table text is too small, the rest scattered
What you get
Merges into four categories: export performance (7), export entry discoverability (5), bulk operations (3), readability (2). Separates what users say from what they hit: 3 of the 7 'too slow' reports are really waiting with no feedback and assuming a freeze, which is a loading-state problem. Each item gets an action and a change type, and discoverability ranks first because it costs least and affects 5 people. The list ends with what not to act on: bulk delete is a low-frequency case, so watch it.
Common mistakes
- Scheduling the raw feedback as requirements — users report symptoms, not solutions, and following them literally often changes the wrong thing.
- Ranking purely by frequency with no view of fix cost or reach — the loudest item may be exactly the hardest to change and the least impactful.
Try tweaking it like this
- Add 'label each category as UI, flow, copy, or performance' — it keeps every problem from being treated as a UI fix.
- Replace 'rank by impact times cost' with 'split into this week, next release, and not doing' — it maps straight onto the schedule and the discussion converges.