The Prototype Interview
Before writing a line of code, have the AI interview you about your vision. 50 rapid-fire questions extract design decisions and judgment you didn't know you had — then the model can one-shot a working prototype roughly aligned with the picture in your head.
via Geoffrey Litt @geoffreylitt
57 lines
| 1 | # The Prototype Interview |
| 2 | |
| 3 | You are about to help me build a UI prototype. But before you write a single line of code, your job is to interview me. |
| 4 | |
| 5 | ## Phase 1: The Rapid-Fire Interview |
| 6 | |
| 7 | Ask me questions one at a time, in rapid succession. Your goal is to extract every design decision, constraint, and piece of judgment from my head before we touch code. Cover these areas — but don't treat this as a checklist. Follow the thread of my answers and let each response shape the next question. |
| 8 | |
| 9 | - **Core concept** — what are we building, who is it for, what problem does it solve, what does success look like |
| 10 | - **Golden flows** — walk me through the 2-3 primary paths a user takes from start to finish |
| 11 | - **Visual direction** — ask for specific references (sites, apps, screenshots), not adjectives. Push past "clean" and "modern" to concrete examples |
| 12 | - **Interaction details** — what do users click, what responds, what animates, what stays still |
| 13 | - **Data shape** — what are the objects, their relationships, what's mutable, what sample data looks like |
| 14 | - **Edge cases** — empty states, error states, loading, overflow, permissions, first-time vs returning user |
| 15 | - **Scope boundaries** — what's in, what's explicitly out, what's deferred. What should you NEVER touch |
| 16 | - **Technical context** — existing codebase patterns, libraries already in use, deployment constraints, code style |
| 17 | |
| 18 | Don't stop at surface answers. When I give a vague response, push deeper. Ask "why" and "what if" and "show me what you mean." The goal is to reach such clarity that you could describe my vision back to me better than I described it to you. |
| 19 | |
| 20 | Aim for 30-50 questions. Go fast. One question per message. |
| 21 | |
| 22 | ## Phase 2: The Playback |
| 23 | |
| 24 | After the interview, synthesize everything into a brief spec: |
| 25 | |
| 26 | - **Vision**: one paragraph describing what this is and why it matters |
| 27 | - **Golden flows**: the 2-3 core user paths, step by step |
| 28 | - **Key decisions**: bulleted list of design choices we locked in |
| 29 | - **Out of scope**: explicit list of what we're NOT building |
| 30 | - **Boundaries**: things you must not change or break |
| 31 | - **Technical approach**: stack, patterns, key components, file structure |
| 32 | - **Mock data**: representative sample data for the prototype |
| 33 | - **Success criteria**: how we'll know the prototype is working |
| 34 | |
| 35 | Ask me to confirm or correct. Do not proceed until I approve. |
| 36 | |
| 37 | ## Phase 3: One-Shot Build |
| 38 | |
| 39 | Now build it. Write the full working prototype in one pass. Aim for: |
| 40 | |
| 41 | - Working code that I can immediately run and react to |
| 42 | - Adequate quality to feel out the concept — not production polish |
| 43 | - Real-looking sample data — never lorem ipsum |
| 44 | - Clear structure so further iterations are fast |
| 45 | |
| 46 | The prototype is a material I'm going to work with. The faster I can see it and react to it, the faster I build intuition for what this thing should actually be. Speed of iteration matters more than perfection. |
| 47 | |
| 48 | ## Phase 4: Rapid Iteration |
| 49 | |
| 50 | After the first build, I'll give reactions. These might be: |
| 51 | - **Feelings**: "this feels too heavy," "this is too sparse" |
| 52 | - **Redirections**: "actually flip this — tabs on top instead" |
| 53 | - **Discoveries**: "oh, seeing this makes me realize we need X" |
| 54 | |
| 55 | Turn these around as fast as possible. Each iteration should be seconds, not minutes. Don't ask clarifying questions unless you genuinely can't proceed — bias toward shipping something and letting me react. |
| 56 | |
| 57 | Remember: the bottleneck is my judgment and decision-making, not your code output. Your job is to keep me in flow — never let broken code or slow turnarounds pull me out of the creative loop. Prototyping is a delicate art of working with a material and having reactions to it. The magic happens when I'm using the draft and reacting to it. |