Prototyping, Handoff & Design–Engineering Collaboration

A prototype is a question made tangible. Build the cheapest thing that answers the current question, then throw it away without grief.

Fidelity ladder — match fidelity to the question

Paper/sketch → wireframe → hi-fi mockup → interactive → coded prototype. Climb only as far as the question demands; each rung costs more and biases feedback more.
Sketches are for getting the right design (many cheap, disposable, ambiguous-on-purpose alternatives); prototypes are for getting the design right (refining one direction). Buxton (2007) makes this the central distinction — a sketch invites critique, a polished comp invites approval.
Houde & Hill (1997): a prototype explores one of three things — role (what it does in someone's life), look and feel, or implementation (can it be built) — plus "integration" prototypes that combine them. Name which one yours is; artifacts that pretend to answer all three answer none well.
Low fidelity is not automatically better: testing visual hierarchy or microcopy needs real type and real content; testing a flow's logic doesn't need color at all.

Test the risky assumption, not the happy path. A prototype that only demos the golden flow is a sales tool, not a research instrument. Prototype the step you secretly doubt: the empty state, the pricing moment, the "what if the data is wrong" branch.
Use real-ish content (long names, zero results, slow states); lorem ipsum hides layout and comprehension failures.
Don't over-polish before testing — participants critique visual finish they'd otherwise forgive, and teams grow attached to what looks done.

A human secretly plays the system (Kelley coined the name in his 1983–84 Johns Hopkins work on natural-language interfaces). Lets you test conversational UI, recommendations, and "smart" features before any model or backend exists.
Especially apt for AI products: fake the model's answers (including wrong, slow, and low-confidence ones) to learn how users react to errors and uncertainty — the part you can't learn from a happy-path demo. Disclose the simulation in debrief.

Specs live in the design system, not in redlines. If a value (spacing, color, type role) is a token or a documented component, the mockup only needs to say which one — per-screen pixel annotations rot instantly and invite drift.
Hand off states, not screens: every screen needs its empty, error, loading, and long-/translated-text versions documented, plus permission and offline variants where relevant. Most "bugs" filed against builds are actually undesigned states.
Annotate for accessibility: intended focus/tab order, reading order, heading levels, ARIA intent (what a control is, what live regions announce), alt-text for meaningful images, touch-target extents. These cannot be inferred from a flat picture.

Schedule design review of the built product before release, against the design system and the documented states — not from memory. Track findings in the same tracker as bugs, triaged with the same seriousness.
Designer–developer pairing beats ticket-tennis: a designer sitting with the implementer for the fiddly 10% (motion, spacing, edge states) resolves in minutes what asynchronous comments take days to converge on.
Design debt = shipped inconsistencies, undesigned states, and one-off components. Log it explicitly and budget paydown like tech debt; unlogged design debt silently becomes "our style."

Critique analyzes whether choices serve stated goals; it is not approval, brainstorming, or taste-jousting. Connor & Irizarry (Discussing Design, 2015): the presenter frames goal + what feedback is wanted; critics tie every reaction to an objective ("does X support Y?"), not to preference.
Lightweight format for mixed groups: "I like / I wish / What if" (Stanford d.school method) — keeps feedback in I-statements and separates observation from prescription.
Timebox, separate critique from decision meetings, and never critique work whose goals nobody in the room can state.

NN/g framing: DesignOps is "the orchestration and optimization of people, processes, and craft to amplify design's value and impact at scale" — so designers can spend their time designing.
Team topologies (Merholz & Skinner, Org Design for Design Orgs): centralized (consistency, weak product context), embedded (context, drift and isolation), hybrid/federated (most common at scale). Choose for the failure mode you can afford.
Designer-to-developer ratios (1:5–1:10 often quoted) are conventions and survey artifacts, not rules — the right ratio depends on surface area, design-system maturity, and how much devs self-serve.

Prompt-to-prototype and design-to-code tools (Figma Make, v0, and similar) now produce working interactive prototypes and passable UI code fast; industry surveys in 2026 report a large majority of designers using generative AI somewhere in prototyping. Treat any tool claim here as dated the day it's written.
Where it genuinely helps: compressing the sketch→interactive rungs, generating many alternatives cheaply (Buxton's point, automated), and scaffolding real-data prototypes.
Honest caveats: output tends toward generic patterns unless grounded in your design system; generated code still needs human review for accessibility, semantics, and performance; and fast fake-real prototypes make prototype honesty (above) more important, because polish now costs nothing and persuades everyone.

Buxton, B. (2007). Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann.
Houde, S. & Hill, C. (1997). "What do Prototypes Prototype?" In Handbook of Human-Computer Interaction (2nd ed.). Elsevier.
Kelley, J. F. (1984). "An iterative design methodology for user-friendly natural language office information applications." ACM Transactions on Office Information Systems, 2(1); NN/g — "The Wizard of Oz Method in UX" (nngroup.com).
Connor, A. & Irizarry, A. (2015). Discussing Design. O'Reilly.
Stanford d.school — "I Like, I Wish, What If" feedback method.
Kaplan, K. — "DesignOps 101," NN/g (nngroup.com).
Merholz, P. & Skinner, K. (2016). Org Design for Design Orgs. O'Reilly.
Figma — Make / AI product documentation and 2026 designer surveys (figma.com) — fast-moving; verify current capabilities.