The Prototype Is a Language¶

A prototype is a communication tool. It's a translator. It translates the user's needs into information the engineer can work with. It speaks the user's language: the language of UX, of interfaces, of operational workflows.

When the user tries the prototype, they use it in the cases they think of most frequently — because that's how the brain works, it doesn't focus on rare edge cases. Inevitably, they encounter situations they hadn't considered. They go to the developer and say, "Look, here, when this happens, I can't do this."

Here's the critical misunderstanding: project managers and companies think the user is reporting a bug. In 90-95% of the cases I've seen, the user is actually communicating specifications through the language of the prototype. "In this list, I don't have this information" — that's not a bug report, that's a specification expressed through a shared visual-operational language.

The prototype is purely a communication instrument. Nothing more.

The moment of truth¶

After the user tests for hours, days, covering 90-95% of their real cases — the company decides that's sufficient, and the user signs off. "It works, I can do my job with this."

But what the user actually validated are the specifications, not the product.

At that exact moment, the engineer should take that prototype and say: "Throw it away. Let's rebuild from scratch." Because now — finally — they have all the knowledge. They understand the data model, the architecture, the procedures, the edge cases. Now they can design an engineered solution optimized for everything they learned.

The user doesn't know what they want¶

Writing specifications is hard. The user says "I want this" but often has a different need entirely. The skill of a business analyst is to listen to requirements and distill them — to extract normalized operational, mental, and procedural models that represent the essence of the domain. Models that can serve as the foundation of an application implementing the processes the user actually needs.

If the specs were written poorly, companies built exactly what the specs said. The user got something technically conformant but useless. "It's not in the spec" — end of discussion.

The prototype bypasses this problem entirely. Instead of trying to capture everything in written specifications upfront, you build something the user can touch. And through touching it, they communicate what they actually need — in a language both parties understand.

Domain-Driven Design knew this all along¶

Domain-Driven Design is perhaps the closest existing methodology to formalizing this insight. Its core concept is building an ubiquitous language — a common vocabulary shared between developers and domain experts. DDD practitioners know this: the common language is the most important thing. Not the code, not the architecture — the language.

My literature teacher in school used to say something that stuck with me forever: "Words are necessary for the correct formation of thought." She was quoting poets and writers — people from a completely different world than software. I always believed it was true. But I never imagined I'd see it manifest so clearly in my profession.

If words are the infrastructure on which you build thought, then DDD is the implementation of this principle in software: it builds a common language that becomes the architecture of the mental model — the model the user needs and the engineer must build.

The prototype is the embodiment of that language. It's the words made tangible.

This is part 2 of the series "From Software Prototyping to Software Engineering."