AI for Designers (UX, Product, Brand)
Proficient · M19 · lesson 19 of 27 · queued
Preview — browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll →
The Five-Day Research-to-Prototype Loop
📖
now learning

The Five-Day Research-to-Prototype Loop

15 min

Chapter 3.1 gave you the judgment - where AI helps, what it costs to verify, how to keep a human in the loop, when output can ship unreviewed. This chapter spends that judgment on the workflow it was built for: compressing a research-to-prototype cycle that used to take two weeks into five working days without losing the rigor that makes the output trustworthy. This is the lesson where it all becomes concrete. You run a real five-day cycle - Monday research synthesis with Granola and Claude, Tuesday a JTBD map in Notion AI, Wednesday wireframes in UX Pilot, Thursday a hi-fi mock in Figma plus Firefly, Friday an interactive prototype in Figma Make - and at every handoff you name what moved, who authored it, and how it was verified. The artifact is a five-day case study with provenance per artifact: not a story about how fast AI made you, but an auditable record showing that each day's output was checked before it became the next day's input. Speed without that record is just a faster way to compound an error across five days. This lesson is about speed with the record intact.

The Compression, and the Danger Inside It

Two weeks to five days is not a fifty percent improvement; it is a different kind of work. The old two-week cycle had slack - time between steps where errors surfaced on their own, where a sloppy synthesis got caught because you sat with it for three days before building on it. The compressed cycle removes that slack. Monday's synthesis becomes Tuesday's JTBD input becomes Wednesday's wireframe brief, each handoff happening within hours, which means an error in Monday's synthesis does not get three days to reveal itself - it gets baked into Friday's prototype before anyone notices. Compression makes the pipeline faster and the cost of an unverified handoff higher, because there is no slack to absorb a mistake. The faster the loop, the more the verification at each handoff matters, which is the exact opposite of the intuition that going fast means checking less.

This is why the case study's organizing principle is provenance per artifact, not speed. Anyone can run five tools in five days; the question a design lead or a future employer asks is whether the output is trustworthy, and trustworthiness in a compressed pipeline lives entirely in the handoffs. A handoff is the moment one artifact becomes the input to the next step, and it is the only place verification can happen before an error propagates. The discipline of this lesson is to treat each handoff as a checkpoint - a moment where you confirm the upstream artifact is correct enough to build on - and to record that confirmation so the whole chain is auditable. The case study is the record of those checkpoints.

Monday: Research Synthesis with Granola and Claude

The week starts with raw material: eight user-interview recordings, captured and transcribed by Granola. Granola handles the transcription - a definitely-AI step in the sprint-map sense, mechanical and self-correcting - and hands you clean transcripts. Then Claude does the heavy synthesis: you feed it the transcripts with a structured prompt that asks for patterns, pain points, and direct verbatim quotes, and in roughly forty minutes you have a draft synthesis that would have taken you most of a week to produce by hand.

This is the AI-with-manual-check step, and here is where the verification tax gets paid in full. The synthesis is load-bearing - it drives everything downstream - so you check every quote against the source transcript and every claimed pattern against the actual data. This is the step where the model paraphrases the one verbatim that matters ("I stopped using it because I couldn't tell what it just did") into a bland generality ("users had concerns about feedback clarity"), and you only catch it by reading the sources. The handoff to Tuesday is gated on this check: the JTBD map cannot be built on a synthesis you have not verified, because a distorted finding here becomes a distorted job-to-be-done there, and the error is now two steps deep. Record in the case study: Granola transcribed (AI), Claude synthesized (AI, structured prompt logged), you verified every quote against source (human, with the specific corrections noted). That is the provenance entry for Monday, and it is what makes Tuesday's input trustworthy.

Tuesday: The JTBD Map in Notion AI

Tuesday turns the verified synthesis into a Jobs-to-be-Done map. Notion AI helps structure the jobs - you give it the verified pain points and patterns and ask it to propose a JTBD framing, candidate jobs, and priority groupings. But the authorship here is yours, not the model's, because deciding which jobs are real and which are artifacts of the model's framing is exactly the strategic judgment that does not delegate. This is closer to a co-pilot pattern: you and Notion AI work the map together, it proposes structure, you accept, reject, and reorder by hand, and the priority weighting - which jobs the design will actually serve - is your call, defended against the verified evidence from Monday.

The handoff check on Tuesday is different in kind from Monday's. Monday verified factual fidelity (do the quotes match the source). Tuesday verifies inferential validity (do these jobs actually follow from those findings, or did the model invent a job that sounds plausible but is not in the evidence). You trace each job back to the Monday synthesis and confirm it rests on real verified findings, not on the model's pattern-completion. A job with no evidentiary root gets cut, no matter how plausible it sounds, because a fabricated job propagates into a wireframe that solves a problem no user has. Record in the case study: Notion AI proposed the structure, you authored the job selection and priority weighting, each job traced to its Monday evidence. The provenance shows the model's contribution and your override, which is the honest picture.

In a compressed pipeline, the handoff is the only place an error can be caught before it propagates. Provenance per artifact is not bureaucracy - it is the record that each day's output was verified before it became the next day's input.

Wednesday: Wireframes in UX Pilot

Wednesday translates the prioritized jobs into structure. UX Pilot is genuinely good at proposing flow and layout structure - this is its actual strength, distinct from UI fidelity - so you use it to generate wireframe-level flows for the top jobs, and you use it in volume: many candidate structures to react to, an AI-led step where the individual outputs are disposable and your judgment is the filter. You keep a few, discard the rest with reasons, and the kept wireframes are the ones whose structure actually serves the prioritized jobs from Tuesday.

The handoff check on Wednesday verifies fit-to-job: does this structure serve the job it claims to serve, and is the job one of the verified-and-prioritized ones from Tuesday? A wireframe that is structurally elegant but serves a deprioritized or fabricated job is a beautiful answer to the wrong question, and you cut it. This is also where the Generated-Mock tells start to matter even at wireframe fidelity - a flow that borrows a desktop convention that will break on mobile, a structure that has no empty or error state - and you flag these now, cheaply, rather than inheriting them into Thursday's hi-fi where they cost more to fix. Record: UX Pilot generated N flow candidates (AI, prompt logged), you kept three with documented reasons, each mapped to a Tuesday job. The provenance traces the wireframe back through the job to the verified finding, so the chain from raw interview to chosen structure is unbroken and auditable.

Thursday: Hi-Fi Mock in Figma plus Firefly

Thursday is where craft re-enters as the dominant mode. The hi-fi mock is built in Figma, by you, against your design-system tokens - this is the definitely-manual core, the low-frequency high-stakes work the model fumbles: hierarchy, destructive-action treatment, real states, the decisions that serve users. AI plays a bounded supporting role. Firefly generates a specific asset - say an empty-state illustration or a hero image - which is an AI-with-manual-check sub-step: a bounded asset you verify on sight against brand and against the reversibility test's brand-exposure axis before it goes in. Claude might draft microcopy variants you then edit. But the screen itself is hand-designed, because the whole point of the prior three days was to earn the right to design the screen well, and handing the screen to a generator would throw that away.

The handoff check on Thursday is the Generated-Mock Audit applied to your own work plus its AI-assisted parts: one primary action, destructive actions safe, survives the phone, real content and states, and for the Firefly asset specifically, a brand-exposure check because it is a visible, customer-facing element where AI's failure modes are most damaging. The provenance entry is layered: the screen is yours (hand-built on tokens), the illustration is Firefly (prompt logged, verified on-brand, brand-exposure cleared), the microcopy is Claude-drafted and you-edited. This is the honest, layer-by-layer provenance that an L2 hi-fi-with-AI lesson taught and this loop now produces under time pressure, which is the real test.

Friday: Interactive Prototype in Figma Make

Friday makes it clickable. Figma Make takes the hi-fi and produces an interactive prototype - a working, navigable artifact you can put in front of a stakeholder or a test participant. This is an AI-with-manual-check step with real stakes, because Figma Make can produce a prototype that looks faithful to the hi-fi while drifting in exactly the places that matter: the focus order, the responsive breakpoints, whether the destructive action you carefully designed on Thursday still behaves the way you designed it. You verify these before the prototype advances, because a prototype that misrepresents the design to a stakeholder generates a conversation about the wrong thing.

The Friday handoff is the handoff out of the loop - to a stakeholder, a test, or a build conversation - and it carries the reversibility test from the prior lesson. If the prototype is going in front of a CPO (the next lesson's subject) its brand exposure and its fidelity to intent matter; if it is going to an unmoderated test, its behavior under real interaction matters. Record: Figma Make generated the interactive prototype from the Thursday hi-fi (prompt and source frame logged), you verified focus order, breakpoints, and destructive-action behavior (human, corrections noted), and the prototype URL is captured. The provenance is now complete: a five-day chain from eight raw interviews to one clickable prototype, every handoff checkpointed, every artifact attributed.

The Case Study as the Real Deliverable

The prototype is the visible output, but the case study with provenance per artifact is the deliverable that demonstrates L3 capability. It is structured as a per-artifact ledger: for each of the five artifacts, what tool generated it, what the human authored or overrode, how the handoff to the next step was verified, and what was corrected. Read top to bottom, it is an unbroken chain of custody from raw research to shipped prototype, and that chain is what makes the speed trustworthy. A two-week cycle's output was trusted because it was slow and hand-made; a five-day cycle's output is trusted because the provenance shows it was verified at every handoff despite the speed.

This is also the artifact that survives the two hardest questions about AI-augmented work. "Did AI just do this?" - no, and here is the per-artifact record of what AI did and what I did. "Can I trust a synthesis you produced in forty minutes?" - yes, and here is the verification log showing every quote checked against source. The case study converts the suspicious-sounding "I compressed two weeks into five days with AI" into the credible "I ran a verified five-day loop, and the provenance proves the output is trustworthy." That conversion is the entire value, and it is why the lesson's deliverable is the documented loop, not the prototype the loop produced.

Why the Handoffs Are the Skill

The deepest lesson here is that the AI tools are the easy part - anyone can run Granola, Claude, Notion AI, UX Pilot, Figma, Firefly, and Figma Make. The skill that compresses two weeks into five days without shipping garbage is the discipline of the handoffs: knowing that each one is a different kind of check (factual fidelity Monday, inferential validity Tuesday, fit-to-job Wednesday, craft audit Thursday, behavioral fidelity Friday), and refusing to let an artifact become the next input until its check passes. The tools provide the speed; the handoff discipline provides the trust; and the case study records both so the trust is legible.

An L3 designer who can run this loop and produce the provenance is operating at the level the whole program points toward: end-to-end AI-augmented workflow, real shippable reviewable artifacts, senior IC speed and senior IC quality, without supervision. The supervision that used to catch errors between steps has been replaced by the handoff checks, which is exactly what operating without supervision means - the safety system is internal, fast, and recorded. Run the loop on a real project, not a hypothetical one. Name every handoff. Check every artifact before it becomes the next input. Write the provenance as you go, not after, because provenance reconstructed at the end is fiction and provenance recorded at each handoff is evidence. The five-day loop is real and it is trustworthy only if the record is.

When the Prototype Tests Poorly: Diagnosing Through the Provenance

Run the loop, ship the prototype to an unmoderated test or a stakeholder, and sometimes it lands badly. The instinct is to call the loop a failure, but that is usually wrong, and the provenance is how you diagnose which thing actually happened. A poor result has three quite different causes, and only one of them is the loop failing. First, the loop may have been internally sound but the strategic bet was wrong - the prioritized job was not the right one, or the research framed the wrong problem. That is a strategic-correctness failure upstream of every handoff check, and the poor test is the loop working as a cheap way to learn the bet was wrong in five days instead of after a two-week build. Second, a handoff check may have failed and let a propagated error reach the prototype - a distorted finding, a fabricated job - and the provenance is precisely what lets you localize the broken link. Third, the loop and the bet may both have been sound and users simply surprised everyone, which is normal research uncertainty surfaced fast, again a feature.

The diagnosis runs entirely through the provenance. If the handoffs were verified and the strategy was defensible, the loop succeeded by failing fast and cheap, which is what a five-day loop is for. If a handoff was skipped, that is the failure to fix, and the provenance shows you exactly where. A poor test result is data, not a verdict on the loop, unless it traces to a skipped check - and the only way to tell the difference is to have recorded the provenance as you went. This is one more reason the case study is the deliverable: it is not just evidence the work was trustworthy, it is the diagnostic instrument when the work meets reality and reality pushes back.

Key Takeaways

  • Compressing two weeks into five days removes the slack that used to let errors surface on their own, which makes the verification at each handoff matter more, not less - the opposite of the intuition that speed means checking less.
  • The case study's organizing principle is provenance per artifact, not speed. A handoff is the only place an error can be caught before it propagates, so each handoff is a checkpoint and the case study records those checkpoints.
  • Each day's handoff is a different kind of check: factual fidelity (Monday synthesis, quotes vs source), inferential validity (Tuesday JTBD, jobs traced to evidence), fit-to-job (Wednesday wireframes), craft audit (Thursday hi-fi, Generated-Mock Audit plus brand-exposure on the Firefly asset), and behavioral fidelity (Friday prototype, focus order and destructive-action behavior).
  • The tools map to sprint-map columns: Granola transcription is definitely-AI, Claude synthesis is AI-with-manual-check, the JTBD map is co-pilot, UX Pilot wireframing is AI-led, the hi-fi screen is definitely-manual with bounded AI sub-steps, and Figma Make prototyping is AI-with-manual-check.
  • The case study, not the prototype, is the real deliverable, because it converts the suspicious "I compressed two weeks with AI" into the credible "I ran a verified loop and the provenance proves it is trustworthy" - and it survives the two hardest questions: "did AI just do this?" and "can I trust a forty-minute synthesis?"
  • The tools are the easy part; the handoff discipline is the skill. Record provenance at each handoff as you go - provenance reconstructed at the end is fiction; provenance recorded at each handoff is evidence.