This meeting could have been a prototype

There is a point in some digital projects where everyone has spent so much time discussing the product that it starts to feel as if it already exists. In reality, it often exists in eight slightly different versions inside eight different heads.

One person imagines a simple dashboard, another something closer to an operating system. The designer is already thinking about navigation, the developer is wondering where the data is supposed to come from, and someone from management keeps saying it should feel "more intuitive".

At that point, the usual response is to schedule another meeting.

There is only so much you can discuss

Meetings are useful, and I am not suggesting that every conversation should be replaced with a Figma file. But there comes a point where talking about an experience becomes less useful than making part of it visible.

Should this happen before or after that step? Will people understand the navigation? Does the dashboard really need all this information? Is the AI assistant useful here, or does it just look impressive in a presentation?

You can discuss those questions for another hour, or you can build just enough of the idea to make them easier to answer.

Not the full product, and certainly not something polished. Just something concrete enough that everyone is finally reacting to the same thing.

Build the argument

This is what I like most about prototyping.

A prototype turns an abstract discussion into something people can actually respond to. Instead of asking whether users might understand something, you can put it in front of them and observe what happens. Instead of debating whether a workflow feels too complicated, you can click through it. Instead of discussing three possible approaches over several meetings, you can build rough versions and compare them.

The quality of the conversation usually improves immediately because people stop arguing about different interpretations of the same idea.

And sometimes an idea that sounded excellent in a meeting looks considerably less convincing once someone has to use it. That is not a failure. It is exactly the kind of thing you want to find out early.

Rough is often better

A prototype does not need to look finished, and in many cases it is better if it doesn't.

The more polished something looks, the easier it becomes to focus on the wrong details. People start discussing fonts, colours, spacing and whether the logo should be slightly larger, while the much more important question of whether the feature should exist at all remains unanswered.

A rough prototype makes it clear that things are still open to change.

That prototype might be a sketch, a few connected screens, a clickable design or a small piece of working software. The right level of detail depends entirely on what we are trying to learn.

If the question is about navigation, we probably do not need a backend. If we want to know whether an API can handle something unusual, a Figma prototype will not tell us very much. And if the question is whether an AI feature works with actual company data, there comes a point where we have to stop drawing little sparkle icons and connect it to an actual model.

AI makes this much faster

Prototyping has become dramatically faster over the last few years.

Design tools, code assistants and AI can now turn an idea into something interactive in hours, and sometimes in minutes. Things that once required several people and a week of work can often be explored before the next meeting would even have taken place.

That does not mean every idea should immediately become a polished prototype. It means we can test more ideas earlier, which makes it even more important to know what we are trying to learn.

Otherwise, we simply become very efficient at producing impressive-looking answers to questions nobody asked.

Question. Idea. Prototype. Feedback. Decision.

I like to think about the process as a simple loop.

We start with a question. What are we uncertain about, and which assumption could turn out to be wrong?

From there, we develop an idea for how something might work and build a prototype that is just detailed enough to test it.

Then we get feedback, ideally by watching real people interact with it rather than asking everyone in the project whether they like it.

Based on what we learn, we make a decision. We might continue with the idea, change part of it, try a different approach or decide that it is not worth pursuing.

Then the loop starts again with a better question than the one we had before.

The important part is that every round should leave us knowing something we did not know at the start.

Meetings still matter

A prototype does not replace the conversation. It simply gives everyone something real to talk about.

Instead of spending another hour imagining how something might work, you can click through it, challenge it, break it and decide what happens next.

So if you are about to schedule the fourth meeting about the same feature, keep the meeting if you need it. Just consider building something first.

If the prototype turns out to be completely wrong, that is still useful. At least you now know what is worth discussing further and what can be discarded entirely.