Turn messy notes into a brief you can actually use

Define the brief’s destination

A meeting transcript, a handful of screenshots, and several messages can contain enough information to begin work. They rarely arrive as a usable brief. Before asking an assistant to tidy them, decide who will use the brief and what they need to do next.

A designer preparing a screen revision needs different detail from a colleague deciding whether to fund it. Specify the deliverable, its intended reader, and the decision it supports. Keep the first version narrow: one page, one feature, or one campaign. Broad requests encourage a polished overview that may leave the practical questions unresolved.

Create a small source packet

Collect the relevant notes in one place and give each source a short identifier. Include dates, page names, or screenshot references when those details affect interpretation. Keep original wording intact in the packet even if it is repetitive or awkward; a summary should not become the only surviving record.

Use material you are authorized to share with the chosen tool, and remove unrelated personal or confidential information. Keep passwords and access tokens out. If a screenshot is necessary, check what else it reveals. This preparation also improves the task itself by keeping irrelevant material from competing with the evidence you want considered.

Separate extraction from recommendation

First ask for a structured account of what the notes actually contain. Request distinct lists for explicit requests, constraints, unresolved questions, and possible interpretations. Ask the assistant to attach source identifiers and to flag conflicts rather than resolve them silently.

In an invented example, one note requests a larger preview while another asks for a shorter page. Those requests might be compatible, but the notes do not specify the layout that reconciles them. Keep that design decision open. A confident recommendation is still a recommendation, even when it appears beside accurately extracted requirements.

Use a brief with an evidence column

Once the extraction is checked, ask for a draft brief. A practical prompt is: “Using only this source packet, draft a brief with the objective, audience, explicit requirements, constraints, proposed approach, acceptance checks, and open questions. Cite source IDs for requirements. Label your proposals and do not invent missing decisions.”

Treat the output as a working draft. The prompt creates useful boundaries, but it does not guarantee the assistant will respect every one. The brief should make it easy to inspect where a statement came from, and easy to identify what still requires a person’s choice.

• Requirement: what must be true, with its source reference.
• Proposal: a suggested way to meet the requirement, clearly labeled.
• Acceptance check: what someone can observe to judge the result.
• Open question: missing information that could change the work.

Review the transformations, not just the prose

Compare the brief with the source packet. Look especially at words that strengthen a request: “could” becoming “must,” “some customers” becoming “customers,” or a question turning into a decision. Verify source identifiers by opening the referenced material rather than trusting their presence.

Check that conflicting notes remain visible, that no named person has been assigned work without support, and that a proposed acceptance check actually measures the requirement. Remove decorative certainty. “Increase conversion” is not an acceptance check for a layout change unless the team has defined how that outcome will be evaluated.

Save a version people can act on

Keep the approved brief next to the original packet and record the decisions made during review. Give the brief an owner and a revision date. When new feedback arrives, update the affected requirement and note what changed instead of asking the assistant to rewrite everything from memory.

The finished brief should let its reader start work, identify what is still uncertain, and trace a disputed instruction back to its source. That is the useful test of this routine. A shorter document is only an improvement when it preserves the information needed to make the next decision.