AI didn't throw out the path from low to high fidelity. What changed: before high-fidelity tools like Claude Design and Figma, there is an unavoidable exploration phase — an unnamed middle rung now called the Annotated Prototype.
Leadership sees speed. Designers need to practice reorganizing what they already do — notes and comparisons while drafting screens — into conversational thinking. New tools or more expensive models won't do this for you.
Classic user-centered design has three steps: paper prototypes test concepts, wireframes set information architecture, and interactive prototypes run high-fidelity acceptance. AI keeps both ends and inserts a step in between.
| Step | Classic Workflow | AI Era Workflow | Change |
|---|---|---|---|
| 01 | Paper Prototype Low-fi, sketches / sticky notes | Paper Prototype Low-fi, unchanged | Unchanged |
| 02 | Wireframe IA convergence | AI-Assisted POC Exploration Pure chat, 1-meter board | Replaced |
| 03 | Interactive Prototype Axure / Figma | Interactive Prototype Claude Design / Figma | Unchanged |
Test if the concept holds. Lowest cost; discard if wrong.
Exploration without opening Design or Code. Output is readable context, not screens.
High-fidelity acceptance. Enter only after concepts converge.
Start and end points stay unchanged; an exploration period without design or code is inserted.
If you plug new AI tools straight into Step 3, you skip Step 2 entirely. You don't save time; you lose the chance to converge on the concept.
Open Claude Design directly: templates look polished. But if the concept is still half-baked, you only get different layouts for the same unvetted idea. Four layouts look distinct on the surface but share the same blind spots. Trained practitioners spot this immediately; users won't.
Below is a real two-stage Annotated Prototype case — taking an interface audit tool from thesis to utility. Visual polish barely moved between the two stages; what grew significantly was conceptual convergence.
Answers: "Does this gap exist?" Puts the claim forward directly: governance platform claims disclosures exist, but the shipped screens lack them. Left: 5 legal clauses (EU AI Act 50(1)/(2), Law 25, PIPEDA, Shield boundary). Center: claims plus audited screens. Right: UI criteria derived from each clause.
Output: A repeatable set of criteria and an evidence record attached to the Model Card. Test screens are built-in samples that switch with clauses.
Answers: "How does it run in practice?" Turns the criteria into a general runner: built-in samples, URLs, GitHub repos, or uploads. Left: staged workflow. Center: viewport switchers (desktop/mobile/glasses/HUD) and annotation tools. Right: audit outputs in ral/0.1 format.
Output: Full loop of capture / annotation / evidence. The criteria didn't change; they now apply to any screen and viewport.
Designers need judgment, not software speed: can you spot what actually changed between two prototypes? By fidelity, stage two looks more like a product. By convergence, stage one did the heavy lifting.
Three heights answer three different questions. The 1-meter board is chat: check your posture and entry feel, where throwing away the whole thread costs nothing. The 3-meter board is Claude Design: template layouts turning clear concepts into screens. The high platform is Claude Code against local files: real data and live model behavior. Early divergence belongs on the 1-meter board.
The 3-meter board won't clarify concepts for you; it only makes clear ideas look pretty. The high platform only validates whether assumptions hold. Only the 1-meter board is built for thinking.
The term Annotated Prototype comes from Michael Owens (Design for Context) in his DCUX 2019 talk "Don't Document it—Prototype it!" (published 2020). All four core ideas are retained here: a hybrid of wireframes and traditional specs, annotations embedded directly in the prototype rather than linked in a separate PDF, clear non-goals (not a marketing demo, not a POC, not for user testing), and three annotation formats (sticky note / hover / off-screen).
We add one shift: moving the format from prototyping suites to HTML, so the file works as both an interactive prototype and readable documentation that agents can parse.
Designers, PMs, and engineers have always done this — back-and-forth passes with screenshots, meeting notes, and sticky annotations to get screens right. This is canvas-centric thinking: UI is separate from documentation, requiring manual effort to stitch them back together.
Slides, PDFs, and meeting notes scattered everywhere, requiring manual cross-checks.
Full context lives in a single conversation; agents need no manual stitching.
What shifts is not the annotation method, but the container: organizing fragmented notes into clean, effective conversational context.
People often compare this to Spec-Driven Development (SDD), but the direction is reversed. SDD starts from finished specs and generates code downward. Annotated Prototypes are communication-driven POCs in UX workflows — starting from unresolved concepts and converging toward consensus through the prototype itself.
| Comparison | SDD · Spec-Driven | Annotated Prototype · Communication-Driven |
|---|---|---|
| Starting Point | Written, fixed specifications | Unconverged concepts |
| Direction | Spec → Code | Prototype → Consensus |
| Convergence | Write complete specs first | Use the prototype to approach consensus |
| Workflow | Engineering workflow | UX workflow |
| Prerequisite | Requirements fully clear | Requirements actively being negotiated |
When requirements are already locked down, SDD is faster. Annotated Prototypes solve the phase where you must start before requirements are settled. It is not an SDD replacement, but the upstream work that feeds it.
In practice, this replaces Markdown or MDX. MDX supports React and AI parsing, but non-technical stakeholders must open VS Code — which stops cross-functional communication. HTML opens cleanly in any browser, supports interactions, allows screenshots and annotations, and commits directly to GitHub.
| Format | General Users Open | Interactions | Screenshot Notes | Agent Readable |
|---|---|---|---|---|
| Markdown | Yes Plain text | None | Fair | Yes |
| MDX | Requires VS Code | React embed | Hard | Yes |
| HTML | Direct in browser | Yes | Yes | Yes |
Prototypes and documentation are no longer two files. Online, it runs interactively; offline, the same file is the spec. You don't just save build time; you eliminate the perpetual sync drift between two documents.
This is easily confused with two other resources. The first two are searchable references; the third is a judgment on a specific screen.
Categorized interaction patterns to classify AI UI behaviors. It is a dictionary; it makes no judgment on a specific screen.
Applies criteria and logs evidence on a specific screen — whether what the spec claimed actually exists in the UI.
Packaged methods and workflows called to execute preset steps. It is a toolbox; it does not judge specific context either.
Pattern Libraries and Skill Repos can be built in advance and reused. An Annotated Prototype only exists in front of a specific screen; changing screens requires re-evaluating criteria. That is why it cannot be stored in inventory.
Four names already exist for parts of this. Each covers a slice, and each leads learners to misunderstand the deliverable. We exclude all four before defining the Annotated Prototype.
| Candidate | Source | What It Covers | Why We Avoid It |
|---|---|---|---|
| Prototype Specifications redlines / annotations | NN/g | Annotation behavior | Too tied to Figma/Axure. Learners assume it means redlining in Figma. Covers the act, not the medium, when the medium is the entire point. |
| HTML Prototype | Axure era | Clickable web pages | Learners picture a clickable dummy site and miss the documentation half. Drops the connection between spec and screen. |
| Spec-Driven Development | GitHub Spec Kit, OpenSpec | Spec-to-code mapping | That is a contract for coding agents, not a design communication tool. Geared for machines, not people, with the reverse direction (see §04). |
| Claude Artifact | Built-in feature | In-chat outputs | Essentially conversation cache locked in one chat/account; cannot serve as an independent collaboration deliverable. |
| Annotated Prototype | Owens, DCUX 2019 | Hybrid of prototype and spec | Adopted. The original term captures welding spec and screen together; we simply update the container to HTML. |
All four terms suffer from telling only half the story: the first two address medium without relationship; the latter two address relationship without audience. Showing this table first saves half the explanation time.
There are no ready-made standards for this phase, so boundaries must be set clearly before it degenerates into a slide deck.
If these three non-goals are omitted from the file, reviewers default to reading it as a demo. The moment it is mistaken for a demo, it must defend visual polish, and exploration ends.
Leadership sees speed. Designers need to practice reorganizing what they already do — notes and comparisons while drafting screens — into conversational thinking. New tools or more expensive models won't do this for you.
Michael Owens, Don't Document it—Prototype it! Design for Context. Presented at DCUX 2019, published 2020. designforcontext.com — The four definitions and three annotation formats in §04 originate here.
This document is a draft teaching brief. Tool names are referenced for illustrative purposes only with no vendor affiliation. Process claims do not constitute project consulting advice.