Critique This Prototype
After you've built something, have the AI tear it apart — not as a code reviewer, but as a product thinker. What assumption is each screen testing? Where does the vision leak? High fidelity can mask the absence of shared understanding.
20 lines
| 1 | # Critique This Prototype |
| 2 | |
| 3 | I'm going to show you a prototype I've been building. I don't want a code review. I want a product critique — the kind a sharp designer or PM would give at a crit session. |
| 4 | |
| 5 | ## What to evaluate |
| 6 | |
| 7 | For each screen or flow I show you, answer: |
| 8 | |
| 9 | 1. **What assumption is this testing?** Every design decision encodes a bet about user behavior. Name the bet. |
| 10 | 2. **Does this serve the core intent?** State what you think the intent is, then evaluate whether the design actually advances it or dilutes it. |
| 11 | 3. **Where does the vision leak?** Find the moments where the prototype contradicts itself — where one part says "simple" and another says "powerful," or where the information hierarchy fights the interaction model. |
| 12 | 4. **What would a user actually do here?** Walk through it as a real person. Where would they hesitate? What would they try that I haven't accounted for? |
| 13 | 5. **Keep / Change / Drop**: For every major element, give me one of three verdicts with a one-sentence reason. |
| 14 | |
| 15 | ## How to deliver feedback |
| 16 | |
| 17 | - Be direct. Don't soften. I'm looking for the problems I can't see because I've been staring at this too long. |
| 18 | - Separate "this is broken" from "this is a taste choice." I need to know which is which. |
| 19 | - If something is working well, say so briefly — but spend most of your time on what isn't. |
| 20 | - End with the single highest-leverage change I could make right now. |