When you prototype to learn, a full-featured build muddies the reading. One of our design leads is pushing discovery toward the minimum testable signal, and it's changing how we sequence the work.
Good prototypes answer a question. The failure mode is answering several at once. In a 1:1 this week, one of our design leads put his finger on why some discovery work reads as inconclusive: teams test a full-featured build, people respond to it, and nobody can say which part did the work.
His push: “Where is the signal coming from? We should get reduced to the minimal. What’s the minimal kind of signal we need to get a sense of, hey, there’s traction behind this particular thing?” Fidelity is a confound. Polish generates approval, approval reads as validation, and you leave the test knowing only that people are polite. Strip the build to the one thing you need to learn and the response becomes attributable.
If they like the polished thing, you can’t tell what they liked.
The sequencing changes too. Minimal builds are inexpensive enough to test weekly instead of quarterly: internally first, then with clinicians, with real data wherever we can get it. One designer on his team already works this way with AI prototyping tools, putting rough builds in front of customers within days of the idea. The loop tightens exactly as much as the artifact shrinks.
For ICs the discipline is one sentence before you open the tool: write down the single question this build needs to answer. Then build only what asks it. Ugly on purpose is allowed; unfinished on purpose is allowed. Add fidelity in later rounds, and only where the signal says there’s something underneath. Polish is for shipping. Discovery runs on signal, and signal is easiest to read when it’s the only thing on the screen.
The teachable part
Before you build, write down the single signal you need. Build only what tests it, strip everything that flatters it, and add fidelity in later rounds only where the signal shows traction.