Every system we build to serve people assumes they know what they want. Almost none of them do. This is not a problem. It is the most important fact about human communication — and we keep designing around it instead of for it.
There is a design assumption buried in almost every system built to handle human requests, and it is wrong.
The assumption is that the person arrives knowing what they want. That they have, before the interaction begins, completed the internal work of identifying their need, formulating a request, and selecting the appropriate channel. The system’s job, on this view, is to receive the pre-formed request and process it.
This is why IVR systems ask you to say or press a number for your category before they let you speak. This is why intake forms ask you to select the nature of your inquiry before you can describe it. This is why chatbots open with a menu of options before they allow free text. These designs are organized around the assumption that the human has already done the work of categorization — and that the system’s job begins when the human’s internal work ends.
The assumption is false. And the falseness is not a bug in human cognition. It is a feature of living expression.
When people communicate — really communicate, not fill out forms or select from menus — they arrive in a state that is better described as becoming than as knowing. The sentence forms in the act of speaking. The concern finds its shape through the process of articulating it. The request emerges from the conversation rather than preceding it.
This is not a sign of confusion or poor preparation. It is what voice actually is. Voice is the living, unresolved, still-becoming side of human expression. The human speaks before the meaning has completed itself. The words come, and the meaning comes in the words, not before them.
A person calling about a billing concern does not arrive with a neatly categorized dispute. They arrive with an experience — something felt wrong, something seemed off, there’s a number on my statement that doesn’t match what I remember — and the concern crystallizes through the act of describing it. By the time the conversation ends, the person often knows more clearly what they were concerned about than they did when they picked up the phone. The conversation was the clarification, not just the transmission.
A person asking a doctor about a symptom does not arrive with a diagnosis in mind. They arrive with a collection of observations, a timeline of feelings, a sense that something is different, a background level of worry. The clinical picture emerges through dialogue, often in ways the patient did not anticipate. “Actually, now that you mention it…” is one of the most valuable sentences in medicine, and it is only possible because the conversation is a discovery process rather than a transmission process.
A developer describing a feature to an AI does not arrive with a complete technical specification. They arrive with an outcome they want and a rough intuition about how to get there. The specification becomes clear in the describing — and sometimes changes significantly from the initial description as the developer thinks out loud.
This is not an edge case. This is normal human expression. This is what voice is.
The systems we have built mostly cannot handle this.
They can handle the person who arrives already knowing. The person who can say “billing dispute” or “lost item” or “return authorization” and then answer follow-up questions with clear, direct responses. These people exist. But they are not representative. They are the people who have had enough interactions with similar systems that they have learned to pre-categorize themselves before calling — to perform the internal organization that the system requires before arriving.
Everyone else — the person who doesn’t know what department they need, the person whose concern spans multiple categories, the person who needs to tell the story before they can name the need, the person who is figuring out what they want in the act of describing it — these people get filtered, routed, frustrated, and sometimes abandoned.
The IVR says: say or press one for billing. The person’s billing concern is entangled with what might be a service issue that might be connected to a policy question. There is no number for that.
The intake form says: select the nature of your inquiry. The nature of the inquiry is: something feels wrong and I don’t know exactly what. There is no checkbox for that.
The chatbot says: how can I help you today? The person types something long and complex and receives a menu of options that was clearly generated before the person’s message was processed. None of the options fit.
Every one of these failures has the same root: the system assumed the person arrived knowing, and the person arrived becoming.
What would it mean to design for becoming rather than for knowing?
It would mean treating the early part of any interaction not as an intake process but as a discovery process. The goal is not to slot the person into a category. The goal is to understand what is happening for them — what they are experiencing, what they need, what the concern is reaching toward — and let that understanding emerge through the exchange.
It would mean tolerating nonlinearity. The person who starts with the item description and then backtracks to the night and then asks if anyone would have noticed is not giving you bad input. They are giving you a story, and the story contains all the information a structured report would need. The difference is sequencing. A system that can receive nonlinear input and organize it into structured output — without demanding that the human do the organizing in advance — is a system that can actually serve the range of humans who call.
It would mean allowing voice to be voice. Not correcting it into form immediately. Not interrupting the emergence with a category prompt. Letting the meaning find its shape, and then working with the shape once it has found it.
AI, at its best, can do this.
The language model’s core capability — receiving open-ended, ambiguous, nonlinear input and finding structure in it — is precisely what the human’s unfinished arrival requires. Not a menu that pre-categorizes. Not a form that pre-structures. A receiver that can hold the unresolved voice while the voice resolves itself, and then work with what emerged.
But this capability — AI’s genuine advantage over traditional automated systems — is routinely squandered by deploying AI in systems designed for the old assumption. AI voice systems that open with “please say the reason for your call.” AI chatbots that require you to select from a menu before the conversation can proceed. AI intake flows that force the person to categorize before the AI can respond. The same old assumption, now with a more sophisticated-sounding front end.
The assumption is the problem. The human does not arrive already knowing. The human arrives in the middle of figuring out. The first job of any system that wants to serve them is to receive that figure-out — to make space for the voice to arrive unfinished, without demanding that it arrive complete.
This matters beyond AI. It matters for how we design customer service, how we design intake processes, how we design meetings and conversations and feedback sessions and interviews. Every interaction with a human being is an encounter with someone who is, in some sense, still becoming in relation to what they are trying to express.
The system that meets them there — that creates space for emergence, that receives the unresolved without correcting it into structure prematurely — is the system that will actually understand what they need.
The system that demands they arrive already knowing will receive a performance of knowing. It will receive the pre-categorized, pre-structured, self-edited version of the person’s concern — the version that fits the menu — and miss the actual concern that was still forming underneath.
Most of the time, the actual concern is more interesting. It is also more actionable. And it is the one that, if received properly, can be carried forward into something that helps.
The human arrives unfinished. That is not a design problem to solve.
That is the human, being human. The only question is whether our systems are capable of meeting them there.