Prototyping and Building

Module 3 ended with a single section converted from a mockup. This module scales that skill up to the thing designers actually want: a working, clickable prototype with multiple screens, realistic data, and real interaction — built in a working session rather than a sprint of engineering time.

The framing to set up front is the title: prototype first, production later. Agents make it cheap to produce something that looks finished, and that is exactly the danger. A polished prototype can create false confidence — it may skip edge cases, accessibility, real data behaviour, permissions, and error handling, and nobody can tell by looking at it. The discipline this module teaches is as much about labelling and boundaries as it is about building.

Set expectations on what gets built during the module: the worked example is a three-screen flow run in one session, and the exercise asks each participant to scope and run the first screen of a prototype of their own. Participants should arrive with Module 2's setup done and Module 3's review habits fresh, because both get used continuously here.

The most common way prototype work fails with an agent is the same way it fails without one: prototyping the whole feature. The agent will happily build everything you ask for, which makes over-scoping cheaper to start and more expensive to finish — by the third screen of an unscoped build, nobody remembers what the prototype was supposed to prove.

The scoping discipline comes from the school's interactive prototype sprint workflow and the prototype-first article: write down the design question, then the riskiest assumption behind it. If you are testing a new onboarding flow, the question might be whether choosing a role first makes the next step clearer; the assumption is that role-first ordering reduces confusion. The happy path is the single walk a reviewer or test participant takes through that assumption — entry point, a handful of steps, an end state. Everything else is stubbed or skipped unless it is the question.

The out-of-scope list is not an afterthought; it is half the brief. Authentication, settings screens, error handling beyond what the flow needs, responsive breakpoints nobody will look at, and any real backend all go on it by default. Writing the assumption down also gives the session its stop condition, which matters when an agent can keep producing more screens for as long as you keep asking.

This slide carries the central working pattern of the module, and it is grounded in the official guidance reflected in the book's research: long sessions accumulate failed attempts and drift. The anti-pattern is the kitchen-sink prompt — build the homepage, the dashboard, the settings, and the profile page — which fills the context window so that by the third page the agent has effectively forgotten the design decisions it made on the first.

The fix has two halves. The first is decomposition: one screen or one flow per run, with the context cleared between runs. The second is persistence: any decision that must survive across runs — the palette, the type scale, the spacing unit, which components to use — gets written into the project's CLAUDE.md (or DESIGN.md, depending on how the project is set up from Module 2) rather than living only in the conversation. Once a screen comes out right, asking the agent to record those decisions in the instruction file is a one-line request, and every later run starts from them.

The two-corrections rule is worth stating explicitly because designers tend to keep negotiating: if the same problem survives two correction rounds, stop, clear the session, and write a better brief that incorporates what you learned — for example, last time the spacing was too tight, use 32px section gaps minimum. A clean session with a sharper brief almost always beats a long session full of accumulated corrections.

Walk the diagram left to right along the top row, then back along the bottom. The brief is the scoping work from the previous two slides condensed into one document the agent reads: question, assumption, happy path, out-of-scope list, and what may be fake versus what must be realistic. The build step is agent-run and deliberately constrained — existing tokens, existing components, sample data, all inside a clearly marked prototype folder rather than next to production files.

The checkpoint deserves the most discussion time because it is the step new users skip. Take a screenshot at the width the review or test session will actually use, walk the flow yourself end to end, and only then decide: fix and loop, or — if the same issue has survived two corrections — clear the session and re-brief. This is the single-section review habit from Module 3 applied at flow scale.

The second row is where the prototype becomes useful: states and the next screen get added run by run, a blocker-only QA pass protects the eventual review without polishing anything, and the session ends with a clickable artifact behind a small index page, labelled as a prototype. The timings from the school's traced runs are realistic to quote: a happy path holding after two build-loop passes in roughly ninety minutes, and a three-screen flow with variants inside a half day — provided the harness of tokens and components already exists.

Designers already know that lorem ipsum and three tidy cards hide problems; the difference with an agent is that realistic data stops being tedious to produce. Asking for a sample dataset shaped like production — the same field names, plausible values, realistic record counts — is a one-paragraph instruction, and the agent will generate names that overflow, dates in the right format, and prices with the right number of digits. Specify the shape rather than accepting whatever the agent invents, because invented data trends towards convenient.

Edge lengths are the high-value request: the longest plausible name, the empty list, the list with dozens of items, the description that wraps to four lines. These are the cases that break layouts in production and that static mockups quietly omit. The prototype-first article's rule applies here: fake data is allowed, but label it clearly — keep it in its own file, named so that nobody later mistakes it for a real integration.

The boundary to hold is between realistic and real. The prototype does not need a backend, an API, or permissions; it needs data that behaves like the real thing for the duration of one walkthrough. Loading, empty, and error states only need to exist where they affect the flow being tested — a plain placeholder is enough, but their complete absence means the review will react to a fiction.

The reason to prototype in code at all, rather than in a clickable mockup, is behaviour: anything where the design question depends on real interaction — typing into a configurator and watching the price respond, dragging a date range and seeing a chart redraw, feeling how navigation behaves with real content depth. Those are the questions worth this module's effort, and they are exactly what design tools simulate worst.

The technique is to be explicit with the agent about the difference between behaving and being wired. Navigation between the prototype's screens should work, with state and data passed in the simplest hard-coded way that survives the walkthrough. The interactions the question depends on get built properly. Everything else gets a plain placeholder that looks deliberately unfinished — visible seams in places the review never touches are a feature, because they keep the prototype honest about what it is.

Interaction states are the detail designers care about and agents drop by default unless asked: hover, focus, and pressed states on anything a reviewer will actually touch. The Module 3 lesson repeats here — accessibility and states you have not explicitly asked for and checked will not be there. Verification stays visual: open the prototype in a browser, click through the whole flow, resize the window. If the project is set up with browser tooling from Module 2, the agent can drive the page, take screenshots of each step, and report what a participant would see — but the designer still walks it personally before anyone else does.

This table is the prototype readiness matrix from the school's prototype-first article, and it is the vocabulary to give stakeholders before they ever see a prototype. The four rows are different contracts: a sketch prototype tests layout and story; an interactive prototype tests flow and reaction, with states that may be fake; a code spike tests whether one mechanism is feasible at all, and may ignore the architecture entirely; a production candidate is the only row that claims to be shippable, and it earns that claim by using real components, real states, tests, accessibility checks, and review gates.

The practical use of the matrix is in the brief: tell the agent which kind of artifact it is building, because the goals differ. A prototype maximises learning; production code maximises maintainability, correctness, accessibility, and integration. Without that contract, the agent optimises for the wrong thing — usually for looking more finished than the work justifies.

The risks designers should be able to name out loud: fake data is fine for flow and unsafe for validating real behaviour; hard-coded state is fine for a walkthrough and unsafe as evidence about real users; local components built for speed become dangerous if they quietly duplicate the design system; skipped accessibility can be acceptable in an exploration but must block any promotion to production. Each of these is acceptable only when it is named before anyone makes a decision based on the prototype.

Prototypes built with an agent look better than prototypes used to look, and that raises the stakes of the review. The strongest pattern from the school's case studies is also the riskiest: handing the laptop across the table and letting stakeholders or clients walk the flow themselves, with their own categories and realistic data. It is far more persuasive than a slide of static screens — and precisely because it is persuasive, the caveats have to be delivered before the walkthrough, not after.

Structure the review around the learning goal. Open with the question and the assumption, so reactions land on the decision rather than the colour palette. State plainly what is fake: this data is sample data, these two screens are stubs, there is no real backend, accessibility has not been done. Capture what people say about the assumption — that is the evidence the prototype was built to produce.

Close with the promotion language from the next slide so expectations are set in the same meeting: which patterns the team intends to keep, what would be rebuilt properly, and what gets discarded. The failure mode to avoid is a stakeholder leaving the room believing they saw a nearly finished product; that single misunderstanding converts a half-day prototype into a delivery commitment nobody scoped.

This is where temporary assumptions become permanent debt if nobody holds the line. The mechanism is mundane: prototype files sitting next to production files with similar names get treated as product architecture by the next person — or the next agent — to open the project. The fix is equally mundane: a physical boundary. A prototypes route or directory, named so its status is unmistakable, with the brief, the learning goals, the screenshots, and the review notes kept beside the code so future readers can see what was learned and what was never meant to ship. The brief should also tell the agent explicitly which production paths are off limits.

Promotion is the second guardrail. Before any prototype influences production work, run a promotion review: which decisions did the prototype validate, which parts are worth keeping as design patterns, which parts must be rebuilt properly inside the product's architecture, which states and accessibility work are missing, and which assumptions were fake. The agent is genuinely useful here — it can produce the component map, the missing-states list, and a rebuild plan — but the keep-or-discard decision belongs to the humans, because the agent has no incentive to recommend throwing away its own work.

Be honest that the throwaway rule is organisationally hard. After a good review, someone with authority has to say the prototype still gets archived. The moment prototype code starts shipping, every future prototype inherits production caution, and the half-day sprint stops being half a day.

This traces the onboarding scenario used in the school's prototype-first article through the session arc from the diagram slide, so the steps should feel familiar rather than new. The brief stage did real work before any code existed: writing the question and the happy path surfaced a contradiction — the team wanted to test role-first ordering but the draft brief also asked for an import-first entry — and resolving that on paper cost minutes rather than a rebuilt screen.

The three runs show the decomposition pattern in practice. Run one built only the role-selection screen, and its checkpoint caught the most common drift: invented colours instead of the project's tokens, fixed by pointing the agent back at the token file and then locking that decision into CLAUDE.md so runs two and three started from it. Run two added the second screen and the navigation between them, and the realistic sample data earned its keep immediately — long template names overflowed the cards, a problem a tidy mockup would never have shown. Run three added the dashboard and the empty and loading placeholders, and the blocker-only QA walk found one dead-end click that would have derailed a stakeholder review.

Keep the claims modest and bounded: this is one traced run of a small flow, with a harness of existing components already in place; roughly half a day is a realistic figure for that situation, not a promise. The pattern — bounded runs, checkpoints, locked decisions, honest labelling — is the part that transfers.

The exercise deliberately covers the first run of the arc rather than a whole prototype, because the boundary is the skill: most participants can get an agent to produce more screens, and far fewer can stop at one, review it properly, and bank the decisions before continuing. Steer people towards a flow from their real work — the same project they set up in Module 2 and converted a section of in Module 3 — but if that project is sensitive or unavailable, a fictional product is fine; the brief and the checkpoint behave the same way.

Watch for the common stumbles. Briefs that name a feature but not a question produce style exercises — push for the decision the prototype should inform. Out-of-scope lists that are empty mean the participant has not really scoped. Sample data without an edge case will sail through the checkpoint and teach nothing. And the most frequent miss: skipping the CLAUDE.md step at the end, which is precisely the step that makes screen two cheaper than screen one.

If running this live, have participants swap screenshots and briefs in pairs and ask one question of each other: could you run screen two from this brief plus the locked decisions, without asking the author anything? That question tests whether the decomposition actually happened.

Recap by connecting the bullets into one arc: the scope defines the question, the decomposition keeps quality consistent across screens, the data and states keep the prototype honest about behaviour, the readiness matrix and review habits keep it honest with stakeholders, and the folder boundary plus promotion review keep it out of production. Each piece on its own is small; together they are why a designer can move at prototype speed without creating the confusing pile of half-production code that gives prototyping a bad name.

It is worth naming what made the speed possible in the worked example: the prototype was assembled from components and tokens that already existed. That dependency is the bridge to Module 5. When the system is healthy — components documented, tokens enforced, drift caught — every prototype starts from a running start; when it is not, every prototype re-invents the parts and the drift compounds.

Module 5 points the agent at the system itself: building new components inside the system's rules, generating documentation in the same run rather than after it, and running audits that find token violations and drift with evidence. Participants who did this module's exercise should keep their prototype folder; the audit exercise in Module 5 can be pointed at the very components their prototype used.