Interactive Prototype Sprint and Handoff

This is the capstone module, so the framing is integration rather than new technique. Modules 1 to 5 each taught one part of the loop in isolation: scoping fidelity, turning references into briefs, exploring directions, holding parity, and running visual QA. The sprint is all of those run in sequence under a deadline, with the deadline doing useful work — it forces the scope conversation that an open-ended prototype never has.

The second half of the module is the part teams skip most often: the handoff. A prototype that tests well and then disappears into a folder teaches nobody anything, and a prototype that tests well and gets quietly promoted to production is worse. The handoff is the artifact that makes the sprint worth more than the demo moment, and writing it honestly — built, faked, unknown — is a design skill in its own right.

Set the expectation that the worked example uses real timings from a traced sprint, not idealised ones, and that the exercise at the end asks participants to plan a sprint for one feature on one page. If they did the exercises in earlier modules, the brief and QA matrix they already wrote feed directly into that plan.

The temptation is to treat a sprint as a special event with its own machinery. Resist that. The sprint is the same designer-agent loop the course has used throughout, run faster because the brief, harness, and QA setup already exist. What the calendar adds is a forcing function: the session date is fixed, so every disagreement about scope has to be resolved by cutting scope rather than slipping the date.

The riskiest-assumption framing comes from the interactive prototype sprint workflow. The single most common failure is prototyping the whole feature; the fix is to write down the one belief that, if wrong, changes the design, and to build only the path that lets a participant encounter it. That sentence also gives the sprint its stop condition — done is when a participant can hit the assumption and react, not when the screens look finished.

The last bullet sets up the second half of the module. The sprint's deliverable is not the prototype; it is the answer to the question plus a handoff packet that records how the answer was obtained and what it does not cover. Teams that treat the demo as the deliverable end up with prototypes nobody can safely reuse and findings nobody wrote down.

Planning backwards from the session is the discipline that makes the rest of the week calm. The session decides the device width the QA sweep targets, the data the prototype needs to feel real, and the variants worth building. A prototype tested on a 1280-pixel laptop in a moderated session needs different QA from one sent unmoderated to phones.

The runs-and-gates structure mirrors the loop from earlier modules but at sprint scale. The build loop is one bounded run: build the happy path, capture, compare against the brief, fix, repeat until it holds. The variant fan-out is a second run that only starts once the base is stable, and each variant changes only what its question requires. The QA sweep is a third run, blocker-only, at the session's device width. Between each run sits a human gate, and the mid-sprint critique gets its own slide because it is the gate teams most often skip.

The out-of-scope list deserves emphasis: authentication, settings, error handling beyond what the flow needs, responsive breakpoints the session will never use, real backends. Writing them down is what gives the agent permission to stub them with plain placeholders instead of inventing production machinery, and what gives the team permission not to feel guilty about the gaps — they are recorded, and they reappear in the handoff as known gaps.

Walk the top row first. Monday is human-led: write or finalise the brief, name the riskiest assumption, confirm the harness runs end to end with one command, and fix the demo and testing dates. Tuesday is the agent's day: the bounded build loop — build the happy path from the harness, capture screenshots, compare against the brief, fix, repeat. Wednesday opens with the mid-sprint critique gate, then fans out two or three variants from the working base. Thursday is the blocker-only QA sweep at the session's device width, followed by the testing sessions themselves. Friday is the demo and the packet.

Then walk the drop into the bottom row, because this is the module's argument in one picture: the packet is what survives the sprint. Four things go in it. The prototype itself, behind an index page, labelled by the question each variant answers — engineering walks it as reference behaviour and never copies the code. The spec and findings — states, edge cases, acceptance criteria, and what testing showed — engineering builds from the spec and turns the criteria into the QA checklist. The tokens and components used, with unmapped values flagged — engineering maps them to production components and makes a named decision about every unmapped value. And the known gaps — faked data, skipped states, open questions with owners — which is what lets engineering size the production work without inheriting silent guesses.

Be clear that the five-day shape is illustrative, not sacred. The build loop in the source workflow takes a half day once a harness exists; a week is what it becomes when testing sessions, stakeholder calendars, and the handoff are included. Compressing it to two or three days changes the dates, not the sequence.

The table makes the ownership pattern visible: human, agent, human-then-agent, agent-then-human, human. The expensive human attention lands on Monday, Wednesday morning, Thursday afternoon, and Friday — roughly a day and a half of designer time across the week. The agent absorbs the production hours in between, which is the entire economic argument for the workflow.

The gate column is worth reading aloud, because each gate is a question with a binary answer and a defined remedy. If Tuesday's flow does not hold, Wednesday morning's critique becomes a scope-cutting session rather than a variant-planning one. If a variant changes more than one thing, it gets pulled back to the base rather than polished — variants that differ in everything teach nothing. If participants did not encounter the assumption on Thursday, that is itself a finding worth recording: the flow buried the thing the team needed to learn about.

Flag the honest caveat about timing. The half-day estimate in the underlying workflow assumes a harness already exists — tokens wired in, a usable subset of components, realistic sample data, a one-command dev server. If there is no harness, building a minimal one is the real output of the first sprint, and this table describes the second sprint onwards.

The mid-sprint critique is the gate teams skip most often, usually with the reasoning that the build is going well and stopping would slow it down. The cost of skipping it shows up Thursday morning, when the QA pass discovers the prototype answers a slightly different question from the brief and there is no time left to fix that.

The critique has a narrow job: protect the session. That means walking the happy path as a participant would, on the device the session will use, and checking three things. First, fidelity to the brief — the criteria from Module 1's fidelity decisions, not general polish. Second, that the riskiest assumption is genuinely encounterable: a participant can do the thing and react, rather than look at a static representation of it. Third, invented scope — agents drift towards completeness, and a half-built settings page or an uninvited error-handling system is scope that costs QA time without buying evidence.

The last bullet ties back to the harness discipline from earlier in the course. If the critique keeps producing the same correction — wrong empty-state pattern, off-system spacing, a component the agent keeps rebuilding instead of importing — that correction belongs in the harness or the builder agent definition, so the next sprint does not pay for it again. The critique notes themselves go into the packet later; they are early evidence of what was deliberately left rough.

The session design is mostly standard usability practice and this slide does not pretend to teach moderation. What is specific to agentic prototyping is the relationship between the brief and the findings. Because the brief named the riskiest assumption, the session has a primary question, and the findings document leads with the answer to it — supported by what participants did, not by a vote on whether they liked the prototype.

The pricing-configurator case from the source workflow is a useful concrete shape: six customer interviews, the assumption being that customers would understand usage-based pricing if they could see the price respond to their own inputs. Five of six completed the flow unprompted, and the breakdown-by-default variant produced noticeably fewer trust questions. That is a finding: a sentence about the assumption, with evidence, that settled an argument the team had been having in the abstract.

The last bullet protects the team from a predictable trap. The prototype has known-faked parts — that is the fidelity contract from Module 1 — and participants will sometimes react to them. A complaint about placeholder copy in a stubbed settings page is not a finding; it is noise from a part of the prototype that exists only to keep the flow walkable. Log it, because it occasionally turns out to matter, but do not let it dilute the readout. Stakeholder reviews follow the same rules as user sessions here: the demo walks the question, not the feature.

This is the slide the module is named for. The four-way split — built, faked, unknown, plus what was learned — exists because each category fails differently when it is left implicit. Unrecorded faked parts become production bugs: the hard-coded date range, the permissions that were never checked, the three-item list that never met forty items. Unrecorded unknowns become unfounded confidence: the sprint proved participants could complete the flow with sample data in a moderated session, and nothing more — not feasibility, not performance, not the segments who were not in the room. And unrecorded learnings evaporate; the prototype gets archived and three months later someone re-litigates the decision the sprint already settled.

Production cost is the section designers are most tempted to soften, and the prototype-first article is blunt about why it must not be: a polished prototype creates false confidence, and the promotion decision belongs to a review, not to momentum. The honest sketch usually says that the patterns are validated, the code is not the base, the real work involves real data, real states, accessibility, and integration — and names which existing components the production build should reuse instead of the prototype's local stand-ins.

Date-stamp the document and name the disposal decision in it: this prototype is archived after the readout, and no code is promoted without a promotion review. That sentence, written down with an owner, is what keeps the next sprint cheap — the moment prototype code starts shipping, every future prototype inherits production caution.

This table is where the course's prototype thread meets the handoff-and-spec workflow. The instinct to hand engineering the prototype repository and call it a handoff is strong, because the prototype looks like most of the work. It is not. The prototype encodes behaviour and intent; the spec encodes what to build. Engineering needs both, for different reasons, and the packet keeps them clearly separated.

Walk the rows. The prototype is reference behaviour — the thing a developer opens to feel how the interaction should respond, what the content depth looks like, how the variant that won actually behaves. The spec carries what a developer would otherwise guess: states for every interactive element, edge cases, token mapping, and acceptance criteria written as testable statements. In the source workflow, generating that spec is itself an agent fan-out — one agent per screen, a consolidation pass, then a developer-perspective review that reads the packet as if it had to build it with no access to the designer. That adversarial pass is what turns a packet that looks complete into one that is.

The open-questions list deserves a defence, because it looks like a list of failures. It is the most valuable page in the packet: every entry is a guess that someone would otherwise have made silently, now turned into a decision with an owner and a date. Budget the answer session — typically an hour or two — as part of the sprint, not as follow-up. The handoff also does not replace the relationship: keep one walkthrough call in the plan. The packet makes that call short; it does not make it unnecessary.

The example is the pricing-configurator case from the interactive prototype sprint workflow, stretched across the week so the testing sessions and the handoff are visible rather than compressed into the build afternoon. Say clearly that the timings are from one traced run with a harness already in place — they are evidence the shape works, not a benchmark to hold a team to.

The details worth dwelling on: the build loop took two passes and about ninety minutes because the harness supplied tokens, components, and sample data, so the agent assembled rather than invented. The critique cut one piece of invented scope — an annual-billing toggle the brief never asked for — and that cut is exactly what the Wednesday gate exists to make. The QA pass caught a slider label overflowing at the 1280-pixel width the interviews would use; it would have been the first thing every participant saw. The sessions answered the assumption: five of six customers completed the flow unprompted, and the breakdown-by-default variant drew noticeably fewer trust questions, which settled a month of abstract argument.

The handoff is the part the original case study barely mentions and this module insists on. The faked list named the static pricing tiers, the absent authentication, and the missing tax handling. The spec covered the winning variant's states and acceptance criteria. The archive decision was written down, with an owner — and the prototype was archived the following week, unpromoted, exactly as the brief said it would be. The production build started from the spec and the design system, not from the prototype code.

This slide is the limits section, and it matters because the sprint's biggest risk is its own success. A prototype that demos beautifully and tests well generates momentum, and momentum is exactly the force that turns throwaway evidence into unreviewed production code. The prototype-first article calls this out directly: a polished prototype creates false confidence, and the promotion decision is a design and engineering decision made in a review, not something the prototype earns by looking finished.

The four limits are worth stating without hedging. Feasibility, performance, and the data model were never tested — the data was sample-shaped, the backend did not exist, and the latency was whatever the dev server happened to do. The findings generalise only to the participants and tasks in the session; the segments who were not in the room remain unknowns, and they are listed as such in the handoff. The disposal rule is a human decision with authority behind it, made after a good session, when keeping the code is most tempting. And production design still happens: the patterns that survived review get rebuilt in the product's architecture, with real states, accessibility, and integration — the promotion review from the prototype-first article is the gate that protects that.

The economic argument for the disposal rule is the one that lands with sceptics: the sprint is cheap precisely because the prototype is disposable. The first time prototype code ships, every future sprint slows down to production caution, and the half-day build becomes a week.

The exercise asks for a plan, not a prototype, and the one-page constraint is doing the teaching: a sprint that cannot be planned on one page is scoped too wide, and the participant finds that out now rather than on the Wednesday of the sprint. Steer people towards one feature on one surface — a configurator, a navigation pattern, a single flow — not a product area.

The step that surprises people is drafting the handoff skeleton before anything is built. Writing the headings — built, faked, unknown, learned, production cost — before the sprint starts changes how the sprint is run: the faked list becomes a live document the team adds to as it fakes things, instead of an archaeology exercise on Friday afternoon, and the unknown list keeps the session honest about what it can and cannot answer.

If this is being run as a cohort, have participants swap plans and apply the gates from the day-by-day table as review questions: is the assumption encounterable, does each variant change exactly one thing, could the session date hold if the build slips a day. Plans that survive that review are usually plans worth running, and the natural follow-up is to actually run the sprint within the next fortnight while the harness, brief, and QA setup from the earlier modules are still fresh.

Recap by walking the loop one last time at sprint scale, and point back to where each piece was taught: the fidelity and disposability discipline from Module 1, the brief from Module 2, the variant thinking from Module 3, parity habits from Module 4, and the QA matrix from Module 5. The sprint added the calendar, the testing session, and the handoff — the parts that turn a fast prototype into evidence a team can act on.

Close the course by being honest about what it assumed. The half-day build economics rest on a harness — tokens, components, sample data — that somebody has to build and maintain, and the gates rest on critique skills that improve with deliberate practice. Both have their own courses in the curriculum: the design systems course covers making a system agents can actually compose from, and the review and critique course goes deeper on the gates this course leaned on. Designers working mostly in Claude Code may also want the platform-specific course for the orchestration mechanics the workflows here referenced.

If participants did the exercises throughout, they now have a scoped prototype, an annotated reference, three direction briefs, a parity round, a QA matrix, and a one-page sprint plan. The most useful thing to do next is run the sprint they just planned, within a fortnight, and judge it against this module's gates rather than against how impressive the demo felt.