11. The prototype as a question

§The question this chapter answers: what, exactly, is this prototype supposed to find out?

§Tom Chi, describing the earliest Google Glass prototypes, put it in one line: a prototype is a question, and you should build it in the time it takes to ask one. Most teams build a prototype as a first version of the product and then look for things to learn from it. The order is backwards, and it is the reason most prototype tests produce a list of small fixes and no decision.

§ 11.1Questions, not features#

§Before anything is built, write the questions. Not "loyalty card" or "check-in screen," which are features. "Can a customer be recognized in any of our locations without asking for anything?" is a question. "Can a server know what a regular wants before reaching the table?" is a question. Each is something the prototype could answer yes or no in a stranger's hands.

§Write them in pairs. For every problem you are attacking, one question from the customer's side and one from the operation's side. Products fail at the seam between the two: the customer experience that the operation cannot deliver, the operational convenience that the customer never sees. Pairing the questions puts the seam in the prototype.

§ 11.2The brief written for a machine#

§The central artifact is a requirements document written to be uploaded, not read. It is short and it is different from anything called a PRD before 2023, because its reader forgets nothing and invents anything you leave blank.

§Personas with names and detail. Not "a customer." "Mariana, thirty-four, eats out three times a week, hates being asked for her phone number, remembers the server who remembered her." The tool will design for the person you describe. Describe a real one.

§The rules already decided. Every business rule the team settled in chapter 8, as numbered statements. "Tiers are based on visits, not spend." "A customer is recognized by the reservation, never by facial recognition." If you do not state a rule, the tool will make one up, and it will be plausible, and you will test a product with a rule nobody chose.

§Real data. A paste-ready set of plausible content: real dish names, real prices in local format, real-sounding customer names. Never placeholder text. Strangers read placeholder text as "not finished" and stop taking the screen seriously. When the tool asks for content, paste. Do not let it invent.

§What is out. Explicitly. The five screens allowed, one line each, and the things that will not appear. Ryan Singer calls these no-gos, and they are the most protective lines in the document, because the tool can add a feature in one prompt and will, unless told not to.

§ 11.3Prompting one screen at a time#

§The tools change monthly; the rules for talking to them have held for two years.

§Describe the flow before asking for a screen, then ask for one screen per message. Describe the moment, not the interface: "she just sat down and wants to know she was recognized," not "a home screen with a badge." Ask for the ugly version first. Change one thing at a time. When it fails, describe what you see, not what you wanted. Ask for the failure states: empty, error, no signal. Do not ask for a design system. When you attach an image, say exactly what to take from it. Save the prompts that worked.

§And one rule above the rest: upload only the brief. Never upload the instructions about how to prompt. Teams that upload both watch the tool build screens for the process instead of the product.

§ 11.4The bar and the freeze#

§The quality bar is one sentence: a stranger can tap through it on their own phone with nobody explaining anything. Not pretty. Navigable, on a device they hold, with data that looks real.

§Set a freeze and hold it. Whatever is not navigable at the freeze does not go to strangers. Without a freeze the prototype absorbs every idea anyone has during the build, and the field test becomes a test of the team's last afternoon instead of its questions.

§ 11.5Only build what came from a question#

§This is the rule the whole second half rests on, and AI is why it exists.

§When a feature cost a developer a week, features were rationed by pain. When a feature costs one prompt, they are rationed by nothing, and teams add them because they can: a token unit that looks clever, a gesture borrowed from an airport, a card lifted from a screenshot of a fintech app. Each is plausible. None traces to a question. And so none can fail correctly, because nobody wrote down what it was supposed to prove, and when strangers reject it the team learns only that strangers rejected it.

§ 11.6What you leave with#

§The question board: every question in its pair, numbered. The brief for the machine, with its cover line. The prompts you saved. A prototype a stranger can tap through on a phone, frozen. And, for every screen, the number of the question it answers. A screen with no number does not go to the field.