Human-reviewed feedback consolidation
Consolidate repeated UI feedback without hiding different bugs
Compare the evidence behind repeated observations manually and keep different acceptance boundaries separate.
- ✓Compare conditions as well as wording
- ✓Compare evidence before accepting combined scope
- ✓Keep a clear canonical issue and source context

Fewer duplicates without losing useful distinctions
A coherent backlog item
Combine repeated observations only when they describe one change with a shared, reviewable acceptance boundary.
Preserved evidence differences
Keep the source conditions visible so the team can distinguish a repeated symptom from a related but separate defect.
Honest automation boundaries
Use manual comparison as the basis for grouping and check the destination board for existing tasks yourself.
Repeated wording is not the same as a duplicate
Several reviewers can describe the same confusing save message with different words. They can also use identical words for unrelated failures. A useful consolidation pass asks whether the affected element, triggering conditions, observed result, and intended outcome match. Keep the original evidence available while making that decision. The goal is a coherent unit of work, not merely a shorter issue list or an impressive reduction count.
Compare related evidence manually
Group the relevant screenshots and recordings in a review cycle, then inspect the extracted findings. Compare their conditions manually and document the chosen canonical issue in your own review process. This workflow does not rely on automatic duplicate detection or an external backlog search. A matching phrase is a reason to investigate, not permission to merge distinct concerns.
Compare conditions before combining work
Suppose two recordings show Profile saved disappearing before the user can read it. A third shows an error message covering the save button. The first pair may describe one confirmation timing problem; the third has a different failure and likely needs separate acceptance criteria. Check whether account roles, input conditions, or builds differ. Similar screenshots do not establish a shared implementation cause, so avoid merging solely because the issues appear on the same screen.
Example canonical issue and acceptance criteria
A useful canonical issue could be Profile save confirmation disappears before the result is understandable. Summarize the matching observations and preserve the meaningful conditions from their sources in the description or review notes. Agree with product on the intended confirmation behavior instead of inventing a universal display duration. Acceptance criteria should state that the user can identify the saved outcome under the reported conditions and still use the next action. Review the chosen work before exporting to Trello, and check the tracker for existing tasks manually.
Preserve distinctions during follow-up
Have a person confirm the consolidated scope and note any related but separate defects. Do not assume a consolidation pass proves that all reports share one root cause. After development, verify each materially different source condition that justified the canonical issue. If a repaired state exposes a second problem, record it separately rather than stretching the original task until its acceptance boundary becomes unclear. Human review remains the safeguard against combining concerns that only look alike.
Review repeated findings before combining the work
Let the conditions and intended outcome define the issue boundary.