Turn Conflicting Spoken Feedback into One Agent Brief
Drafted and reviewed using AI assistance.
On this page
Keep each contributor's observation, interpretation and proposed action separate until someone makes the relevant decision. Then write the coding brief from settled choices and constraints, with the source of each choice still available.
This is a manual synthesis method for notes you already have. It works with written feedback or notes made after a conversation; it does not require a meeting recorder, speaker identification or an automatic decision tool.
Keep the three sources visible
Consider a fictional project page. Its narrow mockup shows the project name on two lines and an Export button in the toolbar. The example's existing export contract is a CSV with columns project_id,title,status; its filename rule and download route should stay unchanged.
The following three short notes, role labels and later decisions are invented teaching material. They are not customer quotations, interviews, recordings or observations from a product test.
N1 — Design reviewer: “The project name wraps to two lines in this narrow mockup. I think the toolbar is crowded. Move Export into the More menu and use only an arrow icon, without text.”
N2 — Support reviewer: “The label only says Export; I cannot tell whether that means CSV or PDF. Keep a visible Export CSV button in the toolbar.”
N3 — Release owner R1: “Preserve the current CSV columns, filename rule and download route. We can make the wording clearer first. I have not chosen between the toolbar and the More menu.”
There is useful overlap: all three notes concern the export action. There is also a real disagreement within the example: icon-only versus visible text, and toolbar versus menu. Grouping the notes under “export improvements” must not erase those differences.
Separate what was seen from what was inferred
The GOV.UK service manual's analysis method separates observations, interpreted findings and decisions about actions. The matrix below adapts that distinction to a coding brief; it does not turn these fictional notes into user research.
| Source | Observation or stated constraint | Interpretation | Proposed action | Decision needed | Owner/status |
|---|---|---|---|---|---|
| N1 | Project name wraps to two lines in the mockup | Toolbar may be crowded | Move export into More | Whether placement should change | R1; open |
| N1 | No separate observation establishes that an icon is clearer | An icon may reduce visual weight | Use an arrow without text | Icon-only or visible wording | R1; needs a choice |
| N2 | Current visible label is Export | File type is unclear to this reviewer | Use Export CSV | Exact label for this iteration | R1; needs a choice |
| N2 | No comparative placement test is supplied | Keeping the action visible may help | Retain toolbar placement | Toolbar versus More | R1; open |
| N3 | Preserve columns, filename rule and download route | Existing export behavior is outside the requested change | Wording first | Which wording to use | R1; stated constraint plus pending choice |
An interpretation can be useful without being established. The name wrapping is visible in the fictional mockup; the claim that moving Export will solve it still needs a design decision and a later check.
Do not count two notes from one contributor as two independent votes. The source labels identify where statements came from, not their statistical weight.
Record a choice without inventing agreement
For the worked example, R1 now supplies this decision record:
| Decision | Settled for the first change | Basis |
|---|---|---|
| D1 | Use the visible label Export CSV | R1 selects N2's wording; the icon-only proposal is not selected for this change |
| D2 | Keep the current toolbar location for this change | R1 limits the first delivery; the broader placement decision remains open |
| D3 | Preserve CSV columns, filename rule and download route | R1's constraint in N3 |
| D4 | Make no other layout or export-behavior changes in this delivery | R1's wording-first scope |
The outstanding placement question stays in its own record:
Open decision O1
Question: Should export eventually move from the toolbar into More?
Sources: N1 proposes moving; N2 prefers keeping it visible.
Decision owner: Release owner R1.
Status: Not decided for a future layout change.
Evidence still needed: Compare the actual layout options and their usability.
Current delivery: Keep existing placement; do not implement either future redesign.
Keeping the current location for a small patch is a settled scope constraint. It is not a claim that everyone agreed the toolbar is the best permanent design.
Check the summary before turning it into work
A misleading summary would be:
“The team agreed to simplify export by moving an icon into More.”
That sentence chooses N1's suggestion, drops N2's visible-label preference and claims consensus that the notes never contained.
A traceable summary is:
“R1 selected Export CSV as the visible label for the first change. The existing toolbar location and export behavior stay unchanged. The future toolbar-versus-menu question remains open, with N1 and N2's proposals retained.”
The summary can be shorter than the matrix because the matrix still exists. If someone challenges a sentence, you can return to the note or decision rather than asking a polished paragraph to serve as its own proof.
Copy the completed implementation brief
GitHub's scoped-task guidance identifies the problem, acceptance criteria and relevant file directions as useful inputs. Here is the settled part of the fictional case, ready to adapt to a real project:
Task: clarify the existing export action's label.
Current state:
The project toolbar contains an action labeled Export.
Required change:
Use the visible label Export CSV.
Ensure the action's accessible name identifies the same export action.
Find the existing control and return the exact files you inspected/changed.
Preserve:
- Current toolbar placement and surrounding layout.
- CSV columns project_id,title,status, in that order.
- Existing filename rule, download route and export behavior.
Scope:
Change the label and directly corresponding accessible naming only.
Do not move the control, replace it with an icon-only action,
or redesign the toolbar or export flow.
Checks:
Inspect the visible label and accessible name.
Check that the control retains its existing location and action binding.
Compare the export contract and relevant behavior using the project's
normal checks; separate performed checks from checks not run.
Return:
A focused change, the actual check record and any implementation detail
that prevents the stated scope from being fulfilled.
Decision references:
R1 decisions D1–D4. Keep the original N1–N3 notes available as context.
The brief contains no instruction to explore both placements or invent a compromise. Those are outside its settled scope. The open-decision record can inform later work without becoming another action buried in the same request.
Reuse the method for the next feedback round
Source ID and contributor role:
Original note/reference:
Observation or explicit constraint:
Interpretation:
Suggested action:
Conflict with another source:
Decision owner:
Actual decision or still open:
What may enter the current implementation brief:
Use an owner's explicit decision when proposals conflict. If no choice exists yet, ask the decision question and leave the implementation brief at the constraints already settled. A fluent summary can help people read the material; agreement comes from the decision process, not from the wording becoming smoother.