Product thinking / DIJION
Turning product feedback into actionable work
A record template separating observations, impact and investigation questions across bugs, usability problems and feature requests.
The app is hard to use is useful feedback, but it does not identify a specific implementation task. Make this button bigger may not be the only solution either. Start by understanding what the person was trying to accomplish, what happened and how it affected them.
Separate observation, interpretation and solution
In a fictional reading app, I tapped Save but could not find the article could indicate a persistence defect or a visibility problem. Rewriting it as The button is broken narrows the investigation prematurely. GOV.UK’s research-analysis guidance separates observations, findings and subsequent actions.
Scroll the table horizontally to see all columns.
| Field | Information to capture |
|---|---|
| Task | The outcome the person wanted |
| Observation | What they did and what they saw |
| Conditions | Version, device, connection and relevant screen |
| Impact | Blocked task or lost information |
| Unknown | An explanation that is not yet verified |
| Next step | Reproduction, clarification or design experiment |
Assess type alongside impact
Bugs, usability issues and feature requests may arrive in one queue. Record impact and urgency before sorting them. Lost data or a blocked core task deserves different treatment from a visual preference. Distinguish repeated messages from one person from independent reports by different people.
Compare three fictional records
- Submission failed and my text disappeared: reproduce data preservation and error handling.
- I could not find Search: observe discoverability in the task flow.
- I want to share this list with friends: investigate the context of the sharing need.
These are fictional examples, not actual user quotes. Do not invent scores for frequency, support effort or engineering cost when those values have not been measured. Recording an unknown is more useful than creating a precise-looking unsupported ranking.
Request the context you need
Reproduction does not necessarily require the person’s entire content. Version and steps are often a suitable starting point. If a screenshot is needed, explain how to obscure personal information. Define record access and retention according to the actual process.
Connect the decision back to the record
Use an accurate status such as Investigating, Planned, Fixed or More information needed. After a fix, repeat the original task: changed code alone does not prove the user problem is resolved. When replying, explain the changed behavior in a concrete sentence.
The first useful output is not an elaborate support system. It is one traceable record connecting a comment to the next research or development step.