Take an AI-feature spec to a working Figma Make prototype wired to real model responses — not lorem-ipsum happy paths — including at least one deliberate failure state a test participant can actually hit. The spec you inherit contains errors, and the prototype is only done when a stranger can break it gracefully.
Ravi is a senior designer at Cartouche, a fictional document-management platform, and the AI feature on his desk is "Ask Your Docs" — a panel where users ask natural-language questions about their uploaded contracts and get answers with source citations. The PM's spec reads confidently. Too confidently: it describes a system that never fails, cites a guideline that does not exist, and specifies a confidence display that research warns against. Ravi's job — and yours — is to catch the spec's errors, then build a Figma Make prototype that behaves like the real feature will: sometimes brilliant, sometimes wrong, occasionally refusing. A prototype that only demos the happy path is a lie you tell your usability participants.
SPEC — "Ask Your Docs" v0.9 (PM draft)
Surface: right-hand panel in the document viewer. Input box
with placeholder "Ask anything about your documents…"
Behavior:
1. User asks a question. Answer streams in under 2 seconds.
2. Every answer shows a confidence percentage (e.g. "94%
confident") so users know exactly how reliable it is.
3. Answers cite source passages. Per HAX guideline G23
("always show provenance"), citations are mandatory, so
the model will always find a supporting passage.
4. There is no error state needed: if the model is unsure it
will simply give its best answer. Users prefer an answer
to a non-answer (see NN/g study, 2024).
5. Out-of-scope questions (weather, chit-chat) are handled
the same as in-scope ones, for a seamless experience.
Test scenario: user has uploaded "MSA_Brightline_2025.pdf",
a services agreement. Demo questions: payment terms, renewal
date, termination clause.
Red-line the spec first — fifteen minutes. Check every claim: look up whether "HAX guideline G23" exists (the HAX toolkit's guideline list is public — count them), interrogate the confidence-percentage requirement against what you know about calibrated confidence (can the system actually produce a meaningful "94%"?), and list every failure mode the "no error state needed" line waves away. Write a spec errata with a fix per item. Do not build from the uncorrected spec.
Script the model's real behavior. In your chat AI, generate the response set you will wire into the prototype. Prompt: "You are a document-QA feature answering questions about a fictional services agreement (MSA between Cartouche client 'Brightline' and vendor 'Nexa Services', signed March 2025, net-45 payment terms, 12-month auto-renewal, 60-day termination notice). Produce answers with a short quoted source passage for: (a) payment terms, (b) renewal date, (c) termination clause, (d) a question the document does not answer — liability cap — where you must say the document does not specify it, (e) an out-of-scope question — 'what's the weather in Pune' — where you refuse and redirect." Save all five verbatim.
Design the failure states before the screens. From your errata, define at minimum: not-in-document (honest "this document doesn't specify"), out-of-scope refusal (with a redirect to what the feature can do), and low-certainty answer (hedged language plus a verification affordance — "check the source passage," prominently linked — instead of a fake percentage). Sketch each as a one-line behavior note.
Build in Figma Make. Prompt Make with the corrected design: "A document-viewer app with a right-hand 'Ask Your Docs' AI panel. Chat-style Q&A. Answers appear with a quoted source-passage card (document name + section). Include: a streaming/thinking state, an answer state with citation card, a 'not found in your documents' state, and a polite refusal state for off-topic questions. Clean SaaS style." Iterate with follow-up prompts rather than regenerating from scratch — regeneration burns credits and loses fixes.
Wire in the scripted responses. Replace Make's placeholder text with your five saved responses so the prototype's content is real model output, not designer-imagined output. Map them: three happy paths, one not-in-document, one refusal. If Make supports connecting a live model for the input box, wire it and keep your scripted set as the guaranteed-reproducible path for testing.
Make the failure reachable. A participant must be able to hit the failure state through normal behavior, not via a hidden demo button. Set up the flow so asking about "liability cap" (a plausible, on-topic question) lands on the not-in-document state, and any off-topic entry lands on the refusal. The test of this step: hand the prototype to a colleague with no instructions and see whether they can encounter a failure inside two minutes.
Audit your own prototype. Against your step-3 notes: does the not-found state avoid blaming the user, does the refusal explain scope rather than just declining, does the answer state make the citation checkable (passage visible, not just a chip), and did any fake precision ("94% confident") survive into the UI?
Package the deliverable. Prototype link, the spec errata, your five scripted responses, and the prompt history (Make's iteration trail) with a two-line note on credit usage — which iterations were worth their cost and which you would skip next time.
Wiring scripted real-model responses into a prototype gives you the best of both worlds — authentic AI texture in every answer, and perfectly reproducible sessions when you put participants in front of it in Lab 14.
An AI-feature prototype earns its existence by failing on purpose — scripting real model responses, including the honest not-found and the refusal, is what makes the thing testable instead of just demoable.