Briefing and Design Intent

This module is where the course stops describing the loop and starts equipping the first step of it. Module 1 introduced the loop, Module 2 walked it at working speed; this module goes deep on the single highest-leverage artifact in it: the brief. The framing to establish up front is that briefing is not paperwork before the design work — it is the design work, moved earlier, where it is cheap to change.

Set the evidence expectation. The claims in this module are backed by two traced runs from the school's published articles: the field-notes strip on this site, run with a one-line request and again with a full brief, and a pricing-page task run with a vague prompt and a specific one. The numbers quoted are from those specific runs, not benchmarks, and the slides say so. That honesty matters — participants who have been burned by AI hype will trust measured small claims over sweeping ones.

Also name what this module will not do. It will not teach prompt tricks or magic phrasings, and it will not pretend a good brief substitutes for product judgment. The brief encodes decisions you have already made; making those decisions is still your job.

These numbers come from the school's vague-versus-specific article, where the two prompts were executed verbatim against the same scratch Next.js target with no harness loaded, so the prompt carried everything. Be precise about what is real: the generated code, the audit output, and the iteration counts are artifacts from the run; the elapsed-time figures are estimates of the equivalent interactive session; and the numbers describe these runs, not a benchmark.

Walk the failure on the left first. The vague prompt asked for a pricing page as a genre, and the agent delivered the genre average: gradient hero, three identical cards, fabricated prices, copy that could belong to any AI product. The dangerous part is that it looked confident — polished enough to screenshot, useless for the buyer's actual decision. Three revision rounds improved the surface, because the surface was all the prompt ever specified.

Then the right column. The specific prompt named the buyers, the decision the page supports, the hierarchy, the density, and the banned defaults — and asked for decision criteria before any code. The first draft was already about something. The audit pass deserves a caveat: it checks token discipline, not information design, so it is a partial gate, not a verdict.

Close on the bottom row, because it is the most instructive. Neither prompt said what the comparison should do on a phone, so neither output handled it. A prompt is a vehicle for decisions, not a replacement for making them.

Walk the rows top to bottom and keep returning to the right-hand column, because that is what makes this slide different from a generic brief template: every line exists because the agent does something specific with it. The situation tells the agent which files and surface to read before planning. The user job is what the plan should restate, and it is the line that decides hierarchy and what gets cut. Audience and context set tone, density, and how much polish the draft aims for — a stakeholder review and an internal spike do not deserve the same effort.

Direction and references are where adjectives go to be translated; the next slide covers that translation in detail. System constraints should mostly point at the harness — name the components and tokens to reuse, and let DESIGN.md carry the rest. Output shape decides where the work lands and at what fidelity; a scratch folder for explorations, a component for real work, an audit report when the deliverable is findings rather than pixels. Review criteria are the contract the agent checks itself against before reporting done.

The two strips at the bottom carry the habits. The closing plan-first instruction is what makes the review gate from Module 2 enforceable rather than hoped for. And the harness strip is the discipline that keeps briefs short: anything that would be true for every task does not belong in this one.

This is the translation skill the whole module turns on. Words like clean, modern, premium, elegant, and delightful are fine as a starting mood, but they cannot decide between two layouts, which means the agent decides — and it decides with the most common pattern in its training data. The fix is to name density, hierarchy, rhythm, and restraint as behaviours: what should be seen first, second, and third; whether the surface is sparse or data-dense; what is explicitly off the table.

The restraint row matters most in practice. Anti-patterns named for this specific surface — no numbered-circle process graphics, no decorative gradients, no marketing register — do more work than positive direction, because they block the exact defaults the agent would otherwise reach for. If the same ban shows up in every brief you write, that is a signal it belongs in the harness instead; Module 4 picks that thread up.

The screenshot row deserves a comment of its own. References are evidence, not decoration: tell the agent which traits to read — density, hierarchy, interaction pattern — and which to ignore — brand, colour, copy. Without that instruction it will happily imitate the palette when what you wanted was the table rhythm.

This is the slide that separates briefs that survive contact with real products from briefs that only survive a demo. Static content sections get off lightly — the field-notes strip from the worked example only had to worry about mobile stacking and heading order, and one line in the brief covered it. Interactive surfaces do not get off lightly: an upload flow, a settings form, or a data table fails in its states, and an agent that was never asked about the empty list, the failed request, or the copy that runs three times longer than expected will invent placeholders that look fine and teach nothing.

The practical habit is small: write the states as a short list at the end of the brief, in the same breath as the review criteria, and require the plan to name how each one is handled. That gives the review gate something concrete to check — a plan that skips the error state is visibly incomplete, instead of quietly incomplete.

Connect this back to the pricing-page run from earlier in the module. The mobile gap existed not because the agent was careless but because nobody — the prompt author included — had decided what the comparison should do on a phone. State briefing is mostly the discipline of making those decisions before generation rather than discovering them in review.

The critique contract is the part of the brief most people skip, because it feels like work that belongs at the end. Writing it first does two things. It forces you to define what good means for this task while you are still neutral — criteria written after generation have a way of bending to fit whatever the agent produced. And it gives the agent a self-check it can run before you ever look: the audits, type checks, and verify scripts that catch the mechanical failures automatically.

Use the evidence from the traced runs to show both halves doing real work. The token audit caught the weak field-notes run's ten hardcoded colours and the vague pricing run's thirty-three. The type check caught the briefed run's invented component props — a failure the approved plan looked right about and the implementation still got wrong. That split is the lesson: executable checks catch what is mechanical; the human criteria — does the strip read as part of the page, does the copy hold the site's voice, can a reader tell what the section is for in three seconds — are what your review time is actually for.

Warn against the inverse failure too: a brief whose criteria are all vibes. If every criterion needs a human to squint at the result, the agent cannot self-correct anything, and you become the bottleneck for failures a script could have caught.

This slide scales the briefing canvas up without changing its nature. For the field-notes strip, the packet was minimal: the brief, a one-paragraph note on why the section exists, and a pointer to the existing page. For a redesigned onboarding flow or a new product surface, the brief alone cannot carry the weight — the user job needs the support tickets or research that motivated it, the current state needs screenshots, and the acceptance criteria deserve their own document. Keeping that material as a small folder of files beside the work means the agent can inspect and quote it, and the plan can be checked against it, instead of everything living in one long message that scrolls away.

Borrow the discipline from the school's research-packet practice: separate what the source directly says from what you infer, record where the evidence came from and when it was checked, and attach a confidence level. Low-confidence evidence should trigger a test or a follow-up, not a layout decision. This sounds heavy until the first time an agent designs around an inference you had quietly promoted to a fact.

Be clear about proportionality. A packet is overhead, and overhead has to earn itself. The seven lines are enough for most section-and-component work; the packet earns its folder when the task spans screens, when several people will review it, or when the evidence behind the change is genuinely contested.

This boundary is what keeps briefs short enough to be read and harnesses stable enough to be trusted. The failure mode on one side is the brief that restates the design system: it adds noise, drifts out of date the moment the system changes, and trains everyone — including you — to skip reading briefs. The failure on the other side is a harness stuffed with task-specific instructions that only made sense once, which Module 4 deals with under the name harness bloat.

The diagnostic is repetition. Constraints that show up in every brief — token rules, banned gradients, component naming — are project rules in disguise and belong in DESIGN.md, AGENTS.md, or a skill. Context that is genuinely new each time — the user job, the evidence, the direction for this screen, the criteria — is what the brief is for. The field-notes brief is the model: it points at DESIGN.md and AGENTS.md by name, names three components to reuse, and spends its words on the job, the tone, and the criteria.

Flag the dependency honestly: this division assumes the harness exists. If a participant's project has no DESIGN.md and no instruction file yet, their briefs will be longer for now, and that is fine — the repetition they notice over the next few tasks is exactly the material Module 4 will teach them to move.

This is the cheapest quality step in the module, and the one people skip because it feels like asking for permission to be criticised. The mechanics are simple: in plan mode, paste the brief and the review prompt; the agent reads the project, restates the job, and lists what is clear, what is missing, what is contradictory, and which states are underspecified. The platform keeps it read-only, so the only cost is the two or three minutes it takes to read the response.

The field-notes run is the proof it earns its keep. The brief asked for a compact strip matching the formats grid and, in the same breath, for step descriptions detailed enough to explain the whole workflow. The plan flagged the conflict and proposed a resolution; agreeing took one written sentence. Without the review, that contradiction would have surfaced as a built section that was either too dense or too thin, and the fix would have cost a full revision round.

The suspicion rule is worth saying twice. Real briefs have gaps — yours will too — and an agent that reports none is usually agreeing rather than reading. Making the questions part of the deliverable, as the prompt does, is what separates a genuine review from a polite echo. It does not catch everything: the same run still produced invented component props that only the type check caught. The review gate filters intent; the executable gates filter implementation.

This is the take-home artifact of the module, so spend a moment on how it scales rather than what it says — the lines themselves were covered on the anatomy slide. For a small component each line is one sentence and the whole brief fits on half a page. For a product page, the direction line may need a reference screenshot and the criteria may need to be a list. For a flow, the canvas stays the same and the supporting material moves into the packet from earlier in the module.

Be equally clear about when not to use it. Changing a label, swapping an icon, fixing a spacing bug in a well-harnessed repository — a one-line request is fine, and writing seven canvas lines first is procrastination. The same goes for throwaway explorations you intend to delete: the cost of being wrong is one regeneration, so spend nothing preventing it. The canvas earns its ten minutes when the task has real structure, real states, or a real audience.

The spec-driven-development note is there for participants who work near engineering. GitHub's spec-kit and similar tooling formalise the same spine — intent, constraints, examples, acceptance criteria — at feature scale, with multi-file specs and task breakdowns. The design brief is deliberately the lighter version: borrow the discipline, not the weight.

Module 1 used this run as a before-and-after scoreboard; this slide opens the brief itself, because the value is in seeing ordinary sentences do specific work. Walk the lines against the canvas. The situation named the page and where the strip sits, which scoped what the agent read. The user job did the heaviest lifting: it turned explain how field notes get made into a reader deciding whether to subscribe should see that each note comes from a real experiment — which is why the plan came back with three one-line steps instead of a process explainer. Direction was almost entirely bans, chosen because this exact surface attracts this exact slop: numbered circles, gradients, marketing register. Constraints pointed at the harness files rather than restating them, and named the three components to reuse. The criteria mixed two commands with three human questions.

Then give the honest accounting. Ten minutes to write the brief, most of it spent on the user job — the design decision the loose request had skipped. A few minutes reviewing the plan, which flagged a genuine contradiction and cost one sentence to resolve. One fix round after generation, because the implementation passed the section heading props it does not have; the type check caught it immediately. Roughly twenty minutes end to end against roughly forty for the unbriefed run, and these figures describe this run, not a law.

The closing point is the one to leave in the room: the brief moved the corrections earlier; it did not remove the need for the gates.

This exercise closes the loop opened in Module 1, where participants sketched the task on paper without an agent. Now they run it. The sequencing matters: write the canvas first, then the agent review in plan mode, then the comparison against their original sketch. Most people find the agent's review surfaces something their own sketch missed — usually a state or a contradiction between the direction and the constraints — and that moment is worth more than any slide in this module.

Steer the scope again: a section, a component, a bounded audit. The output should land in a scratch folder or branch, not anywhere that needs cleaning up afterwards. If a participant's project has no executable checks at all, have them write the two or three commands they wish existed — that list becomes input to Modules 4 and 6.

The debrief questions are on the last bullet, and the third one is the bridge: which corrections did the brief prevent, which did the gates catch, and which line would you write differently. Collect the differently answers if running this live. They split into lines that were too vague — usually direction — and lines that were missing entirely — usually states or criteria — and both patterns recur so reliably that participants effectively write the next module's motivation for you.

Recap by connecting the evidence to the practice rather than re-listing the slides. The vague-versus-specific run showed the cost of unstated decisions in numbers — violations, rounds, minutes — and the canvas is simply the list of decisions worth stating. The translation slide and the states slide are the two places where briefs most often stay vague; the critique contract and the brief review are the two places where the brief starts checking itself. The harness boundary keeps the whole thing sustainable.

Be honest one more time about the limits, because the module has earned it: a brief encodes decisions, it does not make them, and even a good brief plus an approved plan did not prevent the invented-props failure — the type check did. The brief moves correction earlier and makes review possible; the gates from Module 2 and the checks coming in Module 6 are still load-bearing.

Preview Module 4 concretely. Everything participants noticed repeating in this module — the token rules, the component names, the recurring bans, the verify commands — is about to get a permanent home: CLAUDE.md and AGENTS.md, path-scoped rules, SKILL.md files, and design tokens treated as agent instructions. The exercise notes they just produced are the raw material for that module's exercise, so ask them to bring the notes along.