Three people read the same user story and see three completely different products.
Engineer sees a table. Designer sees a multistep wizard. Stakeholder assumes that user starts from a dashboard. Each one of them reads the same text and can tell that they understand it fully.
The difference comes up during the build. But at that point each change results in new tasks, changes in scope, another round of decisions to be made.
Thanks to a clickable prototype a team can have this conversation much earlier. Stakeholder goes through the recommended flow, points at a screen and explains that he had something different in mind. A team gets a well-defined problem to solve, before turning an idea into production code.
A prototype shows only a single, aligned interpretation. Its goal is to give people something they can disagree on.
The question steers the artifact
Not every question needs an interface. During a discovery process I choose an artifact based on what I want to verify:
-
UI and UX: I build a clickable prototype. Stakeholder can assess visual hierarchy, order, navigation flow, interaction. They still don’t know the final cost and if it can even be built with current assumptions and constraints.
-
Business logic: I run a script, state machine or a decision table. We together check the rules, state changes and edge cases. This artifact does not design the whole system’s architecture.
-
Intention and constraints: I write them down in plain Markdown. The document preserves a goal, assumptions, compromises and rejected options. It won’t show how a user would experience the final result.
In a document we can preserve a decision log, reasoning and details that we cannot show on a screen. However it’s much harder to answer the question: “how would it work when someone starts to click it?”
If a discussion touches behavior I’d rather use the suggested answer. A few minutes of interaction gives a much better foundation for a conversation than another round of comments attached to a user story.
Three versions before a single decision
In the UI exploration I use the Prototype skill from Matt Pocock. It creates three variants with different structures for the same flow. I can click between them and compare solutions in action.
I rarely choose a single variant as a whole. I take a heading from A, hierarchy from B and interactions from C. By comparing them I search for a variant that I wasn’t able to describe in the initial prompt.
Thanks to the variants I have something to compare. I still need a conversation with a person who knows the user or business to check the product direction.
A prototype can also hide a problem
A well-polished screen looks like progress. It can also create a false feeling that a team confirmed scope and feasibility.
Let’s take an example. Client sees a fully functional checkout and assumes that the whole payment flow is almost done. The prototype does not show retries, refunds, taxes or integration errors. With this flow we can only assess the UX. We still don’t know how to build and maintain the whole payment system.
During a demo we have to separate three topics: suggested elements waiting for feedback, assumptions that the demo relies on, and technical questions left for a future investigation. Stakeholder may assess the UX without treating each screen as a concrete scope definition.
The prototype’s author is responsible for the first review. AI may add a screen that no one asked for or completely omit a core requirement stated by the client. I wouldn’t send such an artifact just because it looks good. I need to verify if it demonstrates a serious, well-defined proposition that I can defend easily during a demo.
Discovery ends with a decision
We use a prototype to define what we want. After that decision we change how we work.
A team needs to describe requirements, data models, integration, security, scaling and further maintenance. It needs a PRD, ADRs and constraints that a real interface would never handle. A wall of Markdown text is fine as long as the topic requires lots of details and someone takes responsibility for each sentence.
I don’t try to turn a prototype into a system specification. I track decisions that I’ve made during the discovery and then design a production-grade solution. The prototype’s code can help to resolve some behaviors but it should not quietly become a foundation of production only because it already exists.
A team can easily compare ideas during exploration. After making a decision they focus on what needs to survive contact with real users and real exceptions.
Before next meeting
Write down a single question that the stakeholder needs to answer.
If it touches an interface, give them something clickable. If it touches business logic, show them a runnable example. If it’s about a goal or edge cases, just write them down without any extras.
Then show them an artifact during a meeting and ask another person to point out a place where your interpretations are misaligned. After resolving these, turn agreements into a plan that a team would really build.