Collision prototyping: the overload was the test

Putting every requirement into one prototype doesn’t produce a design. It produces the argument the team needs to have.

WRITTEN AND DEVELOPED BY JEN SEPSO · AUGUST 2026 · © 2026 JENNIFER SEPSO

I did something designers are usually told not to do.

I put everything in.

Every requirement I could find. Every request someone had made in a meeting. Every idea sitting in tickets, strategy documents, transcripts, research notes, and earlier prototypes.

The result was too much.

That was the point — or at least, it became the point.

I was working on a complicated enterprise product with a long history, several teams, and no single trustworthy source of truth. Different people understood different parts of the system. Requirements overlapped. Some contradicted one another. Others sounded reasonable in writing but became visibly awkward once they occupied the same interface.

AI let me turn all of that material into a working prototype quickly. I could explore multiple directions without spending days wireframing each one.

That speed created a new problem: it was suddenly easy to make far more than anyone could meaningfully evaluate.

At first, I treated this as a production problem. I needed to find the right design.

But the prototype became useful for a different reason. It gave everyone one concrete place to confront what they had collectively asked for.

Before the prototype, conversations were additive:

The team stopped discussing isolated requests and started evaluating the system.

That shift wasn’t incidental. Carlye Lauff and her team spent ten months inside a footwear company watching how prototypes actually got used, and found they work as communication tools — the same object meaning different things depending on who presents it and to whom. Mine did that too. What it communicated was contradiction.

One proposed action looked straightforward in the requirements: a single primary button, one label, one outcome. During the review, a domain expert stopped on it. On a day with no scheduled appointment, that button has to do something else entirely — and only two of the five document types are even permitted without one. It also cannot go live until someone in another part of the organization has marked the person as arrived, in a system nobody in the room owned. One button, three states, none of it written down.

The prototype did not solve that gap.

It exposed it.

That distinction became the basis of a method I now call collision prototyping.

Collision prototyping uses a deliberately over-complete prototype as a diagnostic tool.

Instead of deciding privately which requirements are worth showing, the designer puts the competing ones in one place. The team judges them in context.

The maximal prototype is not the proposed final design. It is a temporary collision surface.

Lim, Stolterman, and Tenenberg put it well: a prototype isn’t only something you test, it’s a way to move through a design space. Its incompleteness is the point — it shows some possibilities and limits while hiding others. Collision prototyping just widens what’s showing, long enough for the team to watch things collide.

I’m not the first person to build something in order to start an argument. Preben Mogensen called the broader move provotyping — artifacts made to provoke rather than propose, built to expose discrepancies in how work actually gets done.

Collision prototyping is a variant of the same instinct: provocation by aggregation rather than by exaggeration. Here, the provocation is something the team can operate, which is why the button got caught: nobody was reading about it, they were clicking it.

Clarify and Escalate matter because they name a gap and give it an owner instead of letting it pass as agreement.

The prototype becomes smaller, but the team’s understanding becomes larger.

This is the part people skip.

Collision prototyping is not an argument for shipping overloaded products. It would be overdesigning if I treated the result as the solution; I’m treating completeness as a temporary diagnostic state. The maximal artifact is scaffolding: if it survives intact, the subtraction failed.

There is a real risk in this. A maximal artifact shown to the wrong room reads as a proposal. Someone senior sees it without the framing, anchors on it, and now you are arguing against a design you built in order to take apart. I kept it out of the build pipeline entirely. It stayed the review artifact; the handoff to engineering was a separate deliverable, made after the cuts. And I said what it was before anyone looked at it — that it was built to be argued with.

The failure I actually hit was a different one. In one session a decision got reversed inside the same hour — a set of metric cards went in, then came back out in favor of a narrative summary — and when the meeting ended the build still held the earlier version. Live decision-making outruns live building. The artifact is not the record. Run this without writing down what got decided and when, and the prototype will quietly start lying to you about what the team agreed.

Traditional rapid-prototyping guidance recommends scoping the artifact tightly and avoiding “prototype creep.” That remains good advice for a prototype meant to test a direction. Collision prototyping is a temporary exception: expand the scope to expose conflict, then remove what does not survive review.

Writing about enterprise UX, Yegor Gilyov warns that AI prototyping without a clear conceptual model produces structural ambiguity — prototypes built on assumptions that keep shifting. Collision prototyping is built to expose that ambiguity before the team mistakes it for agreement.

It also won’t fit every project. This works when the requirements are fragmented, contradictory, or too abstract to argue about source by source. If yours are clear and everyone agrees on them, you don’t need a collision surface. You need a prototype.

What AI changes is how many candidates we can now produce, and how fast. It also changed the economics of building something you intend to delete — the over-complete version used to cost more than the decision it informed.

It isn’t only a speed story. In a 2025 CHI study, product managers, engineers, and designers prototyped together in a shared prompting tool. All three ended up working in the same material, which blurred who owned which decision and made the system’s behavior harder to read.

But cheap variation has consequences.

In my experience, clients who receive too many prototypes become overwhelmed. Details get missed. Feedback fragments. Sign-off slows because the team is being asked to evaluate more than it can absorb. Pallavi Sharma found the same thing happening upstream: more options tend to mean slower decisions and more second-guessing, not better ones.

Collision prototyping gives that abundance a purpose: build enough to find the uncertainty, reconcile competing requirements, and decide what stays.

What I can say is that the artifact changed the conversation.

I logged the first three review sessions. Seventy-five decisions. Nineteen reversals or cuts. Nine deferrals. And seven requirements that had not existed on paper until somebody encountered the prototype — including the button that turned out to be two buttons.

It exposed redundancies that had remained harmless only because they were scattered across different sources. It helped the team distinguish necessary product behavior from accumulated possibility.

This wasn’t a controlled experiment. I don’t have an alternate-universe version of the project to compare against, and I can’t claim the prototype caused every one of those decisions. What I can show is chronology: the decision-making changed shape immediately after the artifact landed.

And the work that got cut was real work. Three variants, finished to the point where they were worth arguing about, then deleted. The claim that those hours were worth spending rests on a counterfactual — that the same decision would otherwise have been made later, in development, at higher cost. I believe it. I can’t demonstrate it.

The review only worked because experienced people were in the room — people who knew the domain well enough to spot a contradiction when they saw one.

The prototype was not valuable because it was correct.

It was valuable because it made the project’s uncertainty legible.

That’s the whole idea behind collision prototyping:

Maximize to diagnose. Subtract to design. Then test what remains.

This article draws from my experience designing complex enterprise products. Identifying details, sequences, interface examples, and organizational circumstances have been altered or generalized to protect confidentiality.

Lauff, C. A., Knight, D., Kotys-Schwartz, D., & Rentschler, M. E. (2020). The role of prototypes in communication between stakeholders. Design Studies, 66, 1–34.

Lim, Y.-K., Stolterman, E., & Tenenberg, J. (2008). The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Transactions on Computer-Human Interaction, 15(2), Article 7.

Mogensen, P. (1992). Towards a provotyping approach in systems development. Scandinavian Journal of Information Systems, 4(1), 31–53.

Cerejo, L. (2010, June 16). Design better and faster with rapid prototyping. Smashing Magazine.

Gilyov, Y. (2025, September 24). Intent prototyping: The allure and danger of pure vibe coding in enterprise UX. Smashing Magazine.

Subramonyam, H., Thakkar, D., Ku, A., Dieber, J., & Sinha, A. K. (2025). Prototyping with prompts: Emerging approaches and challenges in generative AI design for collaborative software teams. Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, 1–22.

Sharma, P. (2026, April 29). AI tools promised to speed up design — so why does everything take longer now? Bootcamp.

Written and developed by Jen Sepso · August 2026 © 2026 Jennifer Sepso