We're building more, but are we learning less?
Five questions that help you build with intention
We used to have to earn the right to build. Time, tools, skills, engineers: the cost forced discipline. We didn’t build unless we knew what we were trying to learn.
AI made building almost free. Now we can spin something up in an afternoon, so we do, a lot, constantly, and without much intention. The output looks so polished, our stakeholders stop seeing an experiment and start seeing a product. The window for experimenting closes before we’ve had a chance to use it.
We meant to test something, but instead, we shipped it.
A prototype is an experiment: a method for answering a question. It can be rough or refined, a single screen or a full experience, a sketch on paper or something that looks ready to ship. The format matters, but not as much as these three things:
What are you trying to prove or decide? Don’t explore in general, be precise about what you want to prove or decide. If you can’t answer that, you’re not ready.
Who needs to be part of that decision? The fidelity, the format, the framing: all of it should serve that person’s ability to respond and help you take an informed decision.
What’s the minimum quality needed to take the decision? If we’re trying to answer one question, don’t accidentally answer others, keep it clean. AI is good at filling in blanks and taking decisions for you, without your consent.
The Prototyping Checklist
Answer these questions before you start. If you frame your problem, you can build with intention.
1. What are you trying to prove or decide?
In any real experiment, you decide what question you are trying to answer before you design the experiment.
What decision will this prototype inform?
What assumption are you testing?
Are you exploring (divergent) or validating (convergent)?
If your answer is “to explore the idea,” you’re probably missing the real question.
2. Who needs to be convinced?
Who it’s for determines everything that follows. The fidelity, the format, the framing: all of it should serve that group’s ability to respond usefully.
Who is the audience: your team, users, leadership, engineers?
What should they do or decide after seeing it?
What reaction are you looking for? Do you need buy-in, excitement or just a green light to proceed?
Your audience can’t be “everyone”. One size does not fit all.
3. What needs to feel real?
Not everything needs fidelity. Only the part that carries the question. Fidelity isn’t only about what you’re testing, but it’s also about what you’re communicating.
A prototype that looks finished tells people it’s finished. You’ll get debates about copy, edge cases, even animations. Someone will forward it to someone who wasn’t supposed to see it yet. A rough sketch invites a different conversation: people respond to the idea, not the execution.
Decide what reaction you’re after before you decide how real to make something.
Visual → does it need to look finished?
Data → does it need real or realistic data?
Flow → do users need to move through it?
Behaviour → does it need to respond, adapt, or compute?
Context → does it need to exist in its real environment?
If everything feels real, you’ve gone too far. If the critical part doesn’t feel realistic, you’re testing the wrong thing. If it looks more finished than it is, you’ll have the wrong conversation.
4. What’s the absolute minimum?
Don’t get too excited about how easy it is to build something polished. This is an experiment, not a product.
First, ask if you need to build at all:
Could this be a sketch?
Could you fake it instead of building it?
Is there already something you can reuse?
If you do need to build, build only what carries the question:
One screen or across flows?
Linear or non-linear behaviour?
Happy path or edge cases?
Real data or placeholder?
And be just as clear about what you’re not building:
Which parts of the experience don’t you want to talk about?
What parts are you faking?
What would make this prototype misleading?
Be clear with your audience about what the prototype isn’t doing. It keeps the conversation in the right direction.
5. How will you know it worked?
Knowing what to build is just as important as knowing when you’re done. It’s easy to keep on building on your first idea and create something that gets out of control. To prevent that, define this before you start:
What signal are you looking for?
What would change your direction?
What will you do if the result is inconclusive?
Define success up front to make sure you don’t just rationalise your outcome afterwards.
A final thought
When building was still expensive, intention came with it for free. We didn’t prototype without a reason: we couldn’t afford to. The cost has dropped, in time and money both. The volume goes up, experiments multiply, and intention gets thinner. We build more and learn less. Start with this question: What are you trying to find out? Work your way backwards from there: who needs to see it, what do they need to experience, and where do you draw the line?
Prototyping is a method for answering tough questions. Everything else is noise.