From Reference to Brief

Module 1 established the prototype-first mindset and the discipline around scope and disposability. This module is about the input side: most prototypes do not start from a blank page, they start from a pile of references — screenshots someone admired, a competitor flow the product manager keeps mentioning, a handful of research findings, and the product's own constraints. The skill is converting that pile into a brief an agent can execute.

Name the failure mode up front, because everyone in the room has either done it or been asked to do it: pasting a screenshot into the agent with the words make something like this. The agent will oblige, and what comes back is somewhere between a derivative layout and a near-clone — generic where the screenshot was specific, and uncomfortably close where the screenshot was distinctive. Both outcomes are bad, for different reasons this module covers.

The module is structured as a pipeline: what to extract from each kind of input, how to annotate a reference so the extraction is explicit, how research findings join the brief, and then a worked example tracing a competitor flow all the way to a prototype. The exercise at the end has participants annotate one real reference from their own work.

The list on this slide is the extraction vocabulary for the rest of the module. Each item is a behaviour: something the reference does that your prototype could also do, in your own components, your own tokens, and your own voice. Density is the most underused one — designers feel density immediately but rarely name it, and unnamed it never reaches the agent. Rhythm covers the spacing and grouping decisions that make a dense screen feel calm or a sparse screen feel intentional. Hierarchy is the reading order. Flow patterns cover step order and navigation models. States are the quiet gold in competitor references: a mature product's empty states and error recovery represent years of support tickets you did not have to receive.

Contrast that with what a reference also carries that you do not want: brand colour, typography, copy voice, illustration style, logo treatments, and content. Those are the parts an agent reaches for first when given a screenshot with no instruction, because they are the most visually salient and the easiest to imitate.

The practical implication is that a reference is only as useful as the sentence you write about it. The school's prompting article makes the same point about screenshots generally: a screenshot is evidence when the prompt says what it is evidence of, and decoration when it does not.

Walk the columns rather than the rows. The clone column is what happens by default: the instruction is one line, the agent imitates what it can see, and what it can see is the surface. The output fights your design system because it was never asked to use it, and it carries a risk profile nobody signed up for — visual similarity to a competitor is exactly the kind of thing that surfaces late, in a legal review or a stakeholder meeting, when the prototype has already gathered momentum.

The borrow column costs one more sentence and changes everything downstream. Naming the trait — table density, row rhythm, the way filters collapse — gives the agent something it can implement in your components. The output reads as part of your product because the brief said to build it from your product's materials. And the named trait becomes reusable: once you have written match the density of reference A, ignore its brand once, you have a pattern you will use in every reference-driven brief from now on.

The last row is the one to linger on. Cloning feels efficient but teaches nothing; the design reasoning stays locked in the screenshot. Borrowing forces you to articulate why the reference works, and that articulation is the design work.

This is the core technique of the module, and it is deliberately small: three labelled lists per reference, written in the brief next to a pointer to the image file. Match is the positive extraction — the traits from the previous slides, named specifically enough that the agent can act on them and a reviewer can check them. Ignore is the firewall: everything that belongs to the reference's owner or the reference's brand stays out. Never is the often-forgotten third list — the parts of the reference that are actively wrong for your product, like a dark pattern, an accessibility failure, or a density level your audience cannot handle. References are not endorsements; a competitor screen can be worth studying and still contain choices you refuse to repeat.

The one reference, one job line matters more than it looks. When a brief contains four screenshots with no roles assigned, the agent averages them, and the average of four references is usually the generic centre this whole course is trying to escape. Assigning each reference a job — this one is for the table rhythm, this one is for the empty state, this one is what not to do — keeps the extraction sharp.

The code excerpt is the format to copy. It lives in the brief or in the briefing packet beside the screenshots folder, so the annotation and the evidence travel together into the agent's context.

Research findings and references answer different questions, and the brief needs the distinction kept clean. A reference says this behaviour works somewhere; a finding says this is what our users actually did, said, or failed to do. When the two conflict, the finding usually wins, because it is about your users rather than someone else's.

The discipline borrowed from the school's research-packet practice is the separation of observation from inference, with a confidence level attached. A finding written as users could not find the export action is an observation; add a bigger export button is an inference, and a premature one — it pre-empts the design exploration the prototype exists to do. Confidence matters because findings arrive in very different grades: something you watched five users fail at is not the same as something one stakeholder remembers a customer saying. Marking the difference stops a hunch from quietly hardening into a constraint.

The most useful destination for a strong finding is the review criteria. If the research says users could not tell which plan fits a small team, then a participant in a corridor test can name the right plan within thirty seconds becomes a pass/fail question for the prototype. That closes the loop: the evidence that motivated the work is also the standard the work is judged against. Keep the brief's findings section short and point at the fuller notes in the briefing packet rather than pasting transcripts.

Walk the diagram row by row. Reference screenshots contribute density, rhythm, and hierarchy, and those land in the design direction line of the brief — phrased as match and ignore instructions, the way the annotation slide showed. Competitor flows contribute step order, navigation pattern, and state coverage, which land in the user job and the states list; the gaps in a competitor's flow are often as informative as its strengths, because a state the competitor skipped is a place your prototype can be better. Research findings contribute what users actually struggled with, stated as observations with confidence levels, and they land in the user job and the review criteria. Product context — your components, tokens, constraints, and real content — lands in the constraints and content lines, including the explicit ban on inventing facts.

The vertical reading matters as much as the horizontal one: nothing crosses from the left column to the right column directly. Every arrow passes through the middle — the extraction you wrote down. That middle column is the design work of this module, and it is the part teams skip when they paste screenshots straight into the prompt.

The bottom strip is the firewall and it is deliberately blunt. Brand, copy, palette, logos, and proprietary content do not get extracted, full stop. Putting it on the diagram makes it a shared rule rather than an individual judgment call.

This slide connects the module to the briefing canvas the school teaches everywhere else: situation, user job, audience, direction, constraints, output shape, review criteria, with a plan-first instruction at the end. Nothing about that structure changes when the work is reference-driven. What changes is where the content of each line comes from — and after the extraction work of the previous slides, most lines are already written. The findings sharpen the user job. The annotations are the design direction. The product context fills the constraints, including the real content the agent must use and the explicit instruction not to invent more — the prompting article's pricing-page run is the cautionary tale here, where a structurally excellent page shipped with confidently fabricated prices because no real content was supplied.

Remind people what does not belong in the brief: anything the harness already enforces. Tokens, the component inventory, banned patterns, and verification commands live in DESIGN.md, AGENTS.md or CLAUDE.md, and skills; the brief points at them rather than restating them. Reference-driven briefs are particularly prone to bloat because the screenshots invite description — keep the annotations tight and let the images carry the detail.

The closing line is non-negotiable for prototype work of any real size: plan first, in a plan mode where the platform supports one, so the extraction can be checked against the plan before anything is built. The plan is where you find out whether the agent read match the density as clone the layout.

Take the three main reasons in order, and keep the legal one conservative: this course is not legal advice, and the point is not that every resemblance is actionable. The point is that distinctive visual identity — layouts that function as brand, icon sets, illustration styles, copy — is the kind of thing trade-dress and unfair-competition arguments are made of, and a prototype that drifts into that territory creates a conversation with legal that arrives at the worst possible time, after stakeholders have seen and liked the work. Agents make this easier to stumble into, not harder, because they are very good at faithful imitation when that is what the prompt implies.

The taste argument is the one designers feel most directly: a clone inherits every compromise the reference made for reasons you do not know, and it caps your quality at the level of someone else's decisions. The product-fit argument is the practical one — the reference was built for different users, different content lengths, different constraints, and the closer you copy it the more of that mismatch you import. The process point rounds it out: cloning skips the articulation step, so nothing is learned and the next brief starts from zero again.

The last bullet is the one people will actually use. Stakeholders ask for exactly like theirs constantly, and a flat refusal reads as preciousness. The productive answer is to do the extraction with them: what specifically about theirs do you want — the density, the flow, the way it explains the plans? That conversation produces the annotation, and the annotation produces a better prototype than the clone would have been.

The single-reference case is the easy one. In practice a prototype brief draws on several: a competitor's flow, a different product's table density, an internal screen whose empty state the team likes. The failure mode is handing all of them to the agent with equal weight and no roles. The agent cannot tell which trait you wanted from which source, so it averages, and averaged references converge on the generic centre — which is the gravitational pull Module 3 deals with at the level of whole design directions.

The technique is role assignment plus explicit tie-breaking. Each reference gets one job, written in its annotation. When two references genuinely conflict on the same trait — one argues for a dense comparison table, the other for one-plan-at-a-time progressive disclosure — that is a design decision, and it belongs to you, made before the brief is sent. Research is the natural tie-breaker: if your findings say users were overwhelmed by the existing table, the disclosure pattern wins regardless of how much you admire the dense reference. If you genuinely cannot decide, that is a signal the question deserves the multi-direction treatment in the next module rather than a coin flip inside one brief.

The count matters too. Two or three references, each annotated and each with a role, give the agent more usable signal than six raw screenshots. Past three or four, you are usually decorating the brief rather than informing it.

This worked example composes runs the school has published rather than inventing a new benchmark, so present it as an illustrative trace, not a controlled study. The shape of the task mirrors the pricing-page case study from the prompting article and the briefing canvas from the briefing article: a plan-selection surface for a design workflow product, where the real problem was that trial users could not tell which plan fitted them.

Walk the rows as a sequence. The competitor walkthrough is done by hand, screen by screen, and produces two kinds of value: the step structure worth borrowing and the states the competitor never handled — in this trace, what happens when a team is mid-trial and what the downgrade path looks like. The annotation row shows the match, ignore, never lists doing their job: the comparison pattern transferred, the brand did not, and the dark-pattern countdown was explicitly banned. The research row shows a finding with stated confidence becoming the headline review criterion. The brief row shows the plan-first instruction earning its keep — the plan surfaced that mobile comparison behaviour was unspecified, the same residual gap the published pricing run hit, and fixing it cost a sentence instead of a revision round. The build row is deliberately boring: two iterations, clean checks, and a corridor test the next day, which is the speed the prototype-first module promised when the inputs are prepared properly.

The highlight line is the summary of the whole module: structure and gaps from the flow, the pass/fail question from the research, and not one pixel of the competitor's surface in the output.

Close the teaching section with the honest limits, because the failure modes here are subtle — they produce briefs that look thorough and still miss. The first is annotation that asserts what the evidence does not show: writing match its generous spacing when the screenshot is too small or too cropped for the agent to read the spacing at all. If the trait matters, give the agent a usable crop or state the measurement directly.

The second is the seductive reference: a beautiful screen from a product whose users, content, and constraints have nothing in common with yours. Admiration is not evidence. When the reference and the research point in different directions, the research wins, and the published pricing-page run is the standing reminder of the third failure — structure without content. The specific prompt produced an excellent layout with confidently invented prices; only the real content packet fixed it. Reference-driven briefs are especially prone to this because the references supply so much structural confidence that the missing facts go unnoticed.

The fourth limit is the residual-gap rule from the prompting article: whatever no input covered, the agent resolves with the most common default, and for reference-driven work that is almost always responsive behaviour, because screenshots are taken at one width. The fifth is the reminder that nothing in this module replaces the gates: the plan still gets reviewed against the brief, and the rendered prototype still gets looked at — at mobile width, with real content lengths — before anyone calls it done.

The exercise is paper-only and should take ten to fifteen minutes. The constraint that matters is using a real reference the participant already has — the screenshot saved on their desktop, the competitor link in the team channel — because the difficulty of the exercise is articulation, and articulation is only hard when the material is real.

The second bullet carries the standard: the lists are specific enough when a colleague could look at a generated prototype and say whether it matched, ignored, and avoided what the annotation said. Match its clean layout fails that test; match the two-column settings pattern with the section nav on the left passes it. The research bullet deliberately reuses the observation-plus-confidence format from earlier in the module, and the review-question conversion is the part most participants find newly useful.

The last bullet pre-empts the most common annotation failure — claiming traits the screenshot cannot communicate — and asks for the fix: a crop, a measurement, a second reference, or a sentence of description. If running this live, have two or three people read their never list aloud; it is the list people skip when working alone and the one that generates the best discussion about taste and product fit. The page carries forward: Module 3's multi-direction exercise asks for three direction briefs on one task, and a well-annotated reference is ready-made input for at least one of them.

Recap by walking the pipeline rather than the bullet list: inputs, extraction, brief, gates. The inputs are screenshots, competitor flows, research, and product context. The extraction is the written step in the middle — the annotations and the findings — and it is where the design judgment of this module lives. The brief is the same canvas the school teaches everywhere, pre-filled by the extraction and closed with the plan-first instruction. The gates do not change: the plan gets reviewed against the brief, the prototype gets checked against the criteria, and the criteria themselves now trace back to evidence about real users.

Preview Module 3 concretely. A single good brief produces a single direction, and the gravitational pull of the common pattern means even good briefs drift toward the generic centre. The next module is about deliberately writing several briefs for the same task — different information densities, navigation models, and tones — running them in parallel, and converging through a comparison board with named criteria rather than whichever version looked best in the standup. The annotated reference from this module's exercise and the research findings format both carry straight into that work.

If participants kept their Module 1 fidelity-scoping page, point out that the two pages now pair: one says how real the prototype needs to be, the other says what evidence is shaping it.