From Insight to Brief

This is the closing module of the course, and it deliberately confronts the most common failure of research practice — agentic or not. Teams now produce more findings than ever, because agents make coverage and synthesis cheap. The constraint has moved: it is no longer how fast you can produce a research deck, it is whether anything in that deck reaches a brief, a backlog item, or a design constraint that an agent or a teammate actually works from.

Frame the module as the hinge between this course and the rest of the curriculum. Modules 1 to 5 produced research packets of various kinds. The briefing course and the fundamentals course teach how design work runs from a brief. This module is the join: how a validated finding becomes brief lines, constraints, and review criteria, with the evidence still attached so the trace from claim back to quote or data point survives the handover.

Set the honest expectation early: nothing in this module makes prioritisation or interpretation automatic. Agents help with the mechanics — assembling evidence files, drafting brief candidates, keeping the trace intact — but deciding which finding deserves to change the roadmap is judgment, and that stays with the researcher and the design lead.

Open with the failure mode everyone in the room has seen: a strong readout, genuine head-nodding, and a roadmap that does not move. The traditional explanation is organisational — research is consulted too late, or the team lacks a mechanism for findings to enter planning. Both are real, but there is also a format problem: a slide deck of themes is not something a designer, a product manager, or an agent can build from. It has no user job, no constraints, no review criteria, and usually no evidence trail once the deck is exported.

Agents change the economics in a way that cuts both directions. On one hand, synthesis and coverage are cheap, so the volume of findings rises and the gap gets wider — more insight competing for the same planning attention. On the other hand, the same packet discipline that made the research auditable in Modules 1 and 3 gives findings a machine-readable, file-based shape that can flow straight into the briefing structures the design side already uses.

The school's research-packets article makes the same point about editorial work: a signal is not content until it has been translated into relevance, a candidate action, and a decision. Swap signal for finding and editorial decision for brief, and the loop is identical. That parallel is worth naming because it tells the room this is not a new process to learn — it is the same packet loop pointed at design instead of publishing.

This slide is the core mechanic of the module, so slow down here. A finding is descriptive: forty-three per cent of users abandon at document upload, or interviewees do not trust the auto-saved state because nothing confirms it saved. A brief line is obligational: the upload step must work in one pass on a phone camera photo, or every destructive or saving action gets explicit confirmation visible without scrolling. The move from one to the other is not paraphrase — it is a design judgment about what the evidence requires, and different designers can legitimately translate the same finding into different constraints.

The three translations map directly onto the briefing canvas taught in the briefing article and the fundamentals course: the user job line, the constraints line, and the review criteria line. That mapping is the practical reason to do the translation in this shape rather than inventing a new format — the output drops straight into the brief structure the design side already uses, and an agent reading the brief gets the why behind each constraint rather than a bare instruction.

The fourth bullet is the discipline that keeps the whole thing honest. Each translated line carries a citation back to the packet: which theme, which quotes or rows, what prevalence and confidence. Without that, the brief becomes another place where evidence quietly turns into assertion, and three months later nobody can say whether the constraint was grounded or just someone's preference wearing a research costume.

This is the same decision-matrix discipline the research-packets article applies to editorial signals — the question there was does this change what a designer should do on Monday morning, and the question here is does this change a decision this team is about to make. The matrix is deliberately boring. Novelty bias is the failure it guards against: the surprising finding gets the airtime, while the unglamorous one — users cannot find the export button, the error message blames the user — quietly explains most of the support volume.

Walk one or two rows. The first row is the strongest filter: if nobody can name the decision a finding would change, the finding is not low quality, it is just not ready — park it in the packet with a note about what would make it relevant. The evidence-strength row connects back to Modules 3 and 4: prevalence counted honestly, contradictions hunted, weak data not laundered into confident claims. A finding with weak evidence can still be high priority if the decision is cheap to reverse; a finding with strong evidence can be low priority if no decision is in reach. The two axes are independent, which is exactly why conflating them causes trouble.

Agents can help fill this matrix — they can list upcoming decisions from roadmap and planning docs, attach candidate findings to each, and flag findings with no decision attached — but the ranking itself is a judgment about the organisation's intent and appetite, and that is not in the data.

The argument for attaching evidence is not ceremony, it is fidelity under reinterpretation. Every brief gets reinterpreted — by the designer who picks it up, by the engineer who implements it, and now by the agent that drafts the first pass. A bare constraint like keep the upload to a single step is obeyed literally or quietly relaxed depending on who reads it. The same constraint with two support-ticket excerpts and an abandonment figure attached tends to survive contact with implementation, because the reader can see what the constraint is protecting.

For agents specifically, the evidence file does double duty. The briefing article's packet structure already includes an evidence.md precisely so the agent can quote the why back in its plan and use it to resolve ambiguities the brief does not cover. In practice this shows up in plan-mode responses: an agent with the evidence attached will flag when a proposed simplification would reintroduce the friction the research found, which is exactly the kind of catch a plan review is for.

Two cautions. Keep excerpts short and within consent: the brief folder is more widely shared than the research corpus, so quotes must already be cleared for that audience and stripped of identifying detail — the privacy discipline from Module 3 applies downstream too. And resist the temptation to attach everything; the evidence file is the supporting brief for the constraints in this brief, not a mirror of the packet. Link to the packet for depth.

Walk the diagram left to right along the top row, then drop to the bottom band. Validated findings come out of the packets built in Modules 1 to 5: themes with quotes attached, prevalence and confidence stated, sources linked, already interpreted by the researcher. The decision filter is the human gate from the previous slides — which decision does this change, act now or park, what is the cost of being wrong versus waiting. Translate is where the finding becomes brief language: user job, the constraint the evidence implies, the anti-patterns the data rules out, and the review criteria it sets. The brief packet on the right is the structure the briefing article teaches — brief.md, evidence.md, review-criteria.md — which is the point: the research output lands in exactly the shape the design loop starts from.

The bottom-left band is the property that makes the whole pipeline auditable: every brief line can be walked back through its finding and its quotes to a source. That chain is what lets a reviewer challenge a constraint cheaply and what lets an agent explain why a constraint exists. The bottom-right card is Module 6's second half — what shipped, what it moved, and the next question — which feeds a new packet rather than ending the process.

Be explicit about the labour split. Agents are good at the assembly: drafting candidate brief lines from a finding, building the evidence file with citations intact, and checking that no constraint has lost its trace. The decision filter and the translation judgments are human, and the diagram colours them that way deliberately.

The folder on the slide joins two structures the course and the school's articles have already established: the research packet from Module 1 — question, sources, method, findings, evidence — and the briefing packet from the briefing article — brief, user job, evidence, screenshots, plan, review criteria. The only new element is decision-map.md, which records the prioritisation work from earlier in this module: each finding, the decision it could change, who owns that decision, and the call that was made. That file is small and disproportionately valuable six months later, when someone asks why a finding was or was not acted on.

The practical workflow is that the brief folder is created inside the research packet while the evidence is still warm, then copied or linked into wherever design work actually runs — the product repo, the design workspace, the agent-workflows folder. Citations should therefore point at files and stable identifiers rather than at the researcher's memory or a deck page number, so the trail survives the move.

The agent's role here is assembly, and it is genuinely useful: given findings.md and decision-map.md, an agent can draft a candidate brief.md per acted-on finding, pull the cited excerpts into evidence.md, and propose review criteria derived from the metrics or behaviours the finding described. Treat that draft the way you treat any agent first pass — reviewable, not shippable. The translation judgments from slide three still need a human edit, but the human starts from a structured draft instead of a blank page, which is usually the difference between the brief getting written this week and not at all.

Outcome tracking fails when it is designed as a programme. Three short records, kept in the same folder as the brief, are enough: what shipped, what moved, what was learned. The first is written the week the change ships and takes minutes — name the change, the date, and the brief it traces to. The second waits for the data: the review criteria written back on slide three already name the metric or behaviour to check, so this record is mostly a before-and-after against criteria that were set before anyone was attached to the result. The third is the honest one — where the finding held, where it did not, and what the team did not expect — and it is the record people skip and later wish existed.

Agents make the mechanical part of this nearly free. An agent with access to the brief folder, the release notes or merge history, and the relevant analytics export can draft all three records and flag the briefs that have no outcome record at all — which is itself a useful report, because unreviewed outcomes are where research impact silently evaporates. The team's job is to confirm and correct the draft, not to assemble it.

There is also a self-interested reason to keep these records, and it is worth saying plainly: the research function's own case rests on them. When budgets or headcount are questioned, the team that can show three shipped changes traced to specific findings, with movement against pre-stated criteria, has evidence. The team that can show twelve well-received readouts has anecdotes. Be careful, though, not to overclaim causation — a metric moving after a change is consistent with the finding, not proof of it, and the experiment discipline from Module 4 applies to your own outcomes as much as to anyone else's.

The phase model of research — discovery at the start, validation at the end, silence in between — was always a compromise with the cost of doing the work. Agentic research removes most of that cost excuse: journey maps regenerate from fresh data on a schedule, funnels get re-checked after each release, synthesis over the latest quarter of tickets is an afternoon rather than a fortnight. What remains scarce is the researcher's attention, which is exactly why the loop needs a disciplined source of next questions rather than an open call for ideas.

The outcome records from the previous slide are that source. Every record ends with the questions the result raised: the segment the change did not move, the behaviour that shifted in a direction nobody predicted, the constraint that turned out to be too blunt. Those questions go into the next decision map, get filtered by the same decision-relevance test as everything else, and the ones that pass become new packets. The loop closes exactly where Module 1 opened — with a question worth a packet.

Keep the labour split explicit one more time. Agents are well suited to the standing observation work: scheduled regeneration of maps and funnels, drift detection against the last run, flagging when a previously stable finding stops being true. The researcher decides which of the resulting signals deserves a packet, which is the same judgment the research-packets article assigns to the editor: most signals are not articles, and most loop signals are not studies. The loop produces candidates; it does not remove the editorial decision.

Run through these as diagnostics rather than scolding, because every team doing this work hits at least two of them. Novelty-driven prioritisation is the most common and the least visible: the interesting finding gets the brief, the boring one that explains the support queue gets a slide. The dropped-citation failure usually happens at handover boundaries — the brief gets copied into a ticket, the ticket strips the links, and three weeks later the constraint is being argued about as if it were taste. The over-stuffed evidence file is the opposite failure: attaching the whole corpus feels rigorous but guarantees nobody reads it, and it usually breaches the consent boundary the corpus was collected under.

The fourth failure is specific to agentic practice and worth dwelling on. Agents draft good-looking briefs, and a good-looking draft invites a quick approve. But the translation from finding to constraint is a design judgment — the same finding can legitimately produce different constraints depending on appetite, strategy, and what the team can actually ship. An unedited agent brief means that judgment was made by pattern-matching over other people's products. Edit the draft or own the consequence.

The fifth failure is the one that compounds: without outcome records, there is no evidence the research changed anything, no defensible next question, and over time no argument for the function. If you can only fix one thing after this course, fix that one — it is also the cheapest, at three short records per shipped change.

This trace deliberately reuses the claims-upload thread that has run through the course — the funnel diagnosis in Module 4 and the journey rebuilt from tickets in Module 5 — so the example shows the modules joining up rather than introducing a new domain. Present it as an illustrative composite of how the pipeline behaves, with the figures describing this run rather than a promise about effect sizes.

Walk the rows and pause on the ones that carry the module's argument. The decision filter row is what made this finding move when others from the same synthesis did not: the upload step already had a scheduled redesign, so the finding had a decision to attach to. The brief-lines row shows the three translations from earlier — job, constraint, criteria — and notice the criteria were stated before the build, which is what made the outcome record cheap to write and hard to argue with. The build row shows the labour split working as designed: the agent drafted the brief from the packet, and the designer's edit changed real things — tightening one constraint and deleting another the evidence did not actually support.

The outcome row is the loop closing. The improvement is real but partial, and the residue — drop-off now concentrating on desktop scans — is exactly the kind of question that seeds the next packet. That is the shape to leave the room with: not research as a victory lap, but research as a loop where each answer produces a sharper question.

This exercise is the course's exit ticket, and it is deliberately done by hand before any agent touches it, for the same reason the fundamentals course starts its briefing exercise on paper: the hard lines are the judgment lines, and people need to feel which ones those are. In practice the two lines that stall participants are the decision line and the review criteria, and both stalls are informative. If no decision can be named, the finding goes back to the packet with a note — that is the decision filter doing its job, not a failure of the exercise. If the review criteria will not come, it usually means the constraint is still a description of the problem rather than an obligation on the design.

The seven brief lines reuse the canvas from the school's briefing article and the fundamentals course, so participants who have done either will recognise the shape; the addition this module makes is the citation discipline in the fourth bullet and the pre-written outcome record in the fifth. Writing the outcome record before the work ships feels odd the first time and is the single habit most likely to survive the course, because it makes the review criteria honest — you are stating, in advance, what you expect to be able to claim.

If participants want to extend the exercise afterwards, the natural next step is to hand the same finding and decision map to an agent, ask it to draft the brief, and compare against the hand-written one. The differences are usually in the constraints — and examining whose constraint is better grounded is a faster lesson in the translation judgment than any slide.

Close the module and the course by walking the spine one last time. Module 1 made the packet the unit of research; Modules 2 to 5 filled packets with desk research, teardowns, synthesis, quantitative readouts, journeys, and blueprints; this module made the packet pay its way by converting findings into briefs with the evidence attached, prioritising by decision impact, and closing the loop with outcome records that seed the next question. The through-line is the same in every module: agents supply coverage, structure, and traceability; humans supply the questions, the interpretation, the translation into obligation, and the accountability for what ships.

Point people at where the curriculum goes next. The brief packet this module produces is the input the Agentic Design Fundamentals course works from — its briefing, harness, and critique modules pick up the moment a brief exists. The school's workflow library covers each method from this course in operational detail: deep design research, competitive teardowns, user research synthesis, survey design and analysis, experiment readouts, funnel diagnosis, journey mapping, and service blueprints, plus stakeholder workshop prep for the moments when the evidence needs to land in a room rather than a repo. The briefing article and the research-packets article are the two short reads worth assigning if the team only reads two things.

End on the discipline rather than the tooling. Tools and entry points will keep changing — date-stamp anything you teach from this module accordingly — but the loop of question, packet, decision, brief, outcome, next question is stable, and it is the part that makes agent-scale research worth having.