If so, there’s a good chance you weren’t actually having a conversation. You were filling out a form. One that someone had dressed up in a chat window.
I coined a term for this: conversationalization. It’s the practice of taking an existing UI or workflow and recasting it as a conversation without rethinking whether conversation is the right medium, or what conversation actually demands.
Once you know what to look for, you’ll see them everywhere
The bot asks one field at a time, in a fixed order, with no ability to skip, go back, or provide multiple pieces of information at once. It literally feels like filling out a form, and it’s often slower than the form it replaced.
The bot presents a text input field (the universal signal for “type whatever you want”) but can only handle a narrow set of expected responses. It invited open-ended input and then refused to handle it.
The interaction is functionally identical to a form, but the bot says “Great!” after every answer and calls you by your first name. The warmth is at odds with the rigidity, like a service agent who’s unfailingly polite but can’t actually help.
Information that could be collected all at once gets spread across multiple turns for no reason other than to fill the chat window. Each turn adds time, taps, and friction. The user ends up serving the conversation format.
You want AI? Turn it into a conversation.
The way most companies have introduced AI to their users is through conversation. A chat window. A text box. A prompt that says “How can I help you?” When LLM technology took off, suddenly everyone wanted AI, and the form that the industry chose was chat. And when it’s done well, it’s incredible. It can make complex things feel simple. It can meet people where they are.
As the Staff Designer leading the conversation design discipline at ServiceNow, a company that specializes in complex enterprise workflows, I’ve watched this play out on a large scale. Designers across the org are increasingly being asked to turn their products into conversations. Take this form, this wizard, this multi-step workflow, and make it a chat. The sentiment is good. The results, often, are not.
None of this work was lazy. But it was obvious. You want AI? Turn it into an AI conversation. The problem is that creating truly good conversational AI involves more than putting a non-conversational flow into a chat window. There are design patterns, linguistic principles, and interaction norms that make conversations work. And those were being skipped in the rush to ship conversational AI as quickly as possible.
It’s damaging in ways that compound
The temptation is to see conversationalization as harmless. Maybe not optimal, but not damaging either. A form in a chat window is still functional, after all. But it is damaging, in multiple ways, and in ways that compound over time.
Conversationalization erodes trust in conversational AI broadly
Every time a user encounters a bot that’s really just a form with a personality, they update their mental model of what “AI chat” means. And that updated model isn’t good. It’s “this is going to be a rigid, frustrating experience dressed up to look friendly.” That expectation carries forward into every future interaction with every conversational product. You’re not just building a bad experience. You’re training users to expect bad experiences.
Conversationalization wastes the real opportunity
Conversation as an interface is powerful precisely because it can do things forms can’t. When you take a rigid, linear workflow and put it in a chat interface, you’ve made a promise without any of the follow-through. The user shows up expecting a conversation and gets an interrogation.
They expect to be heard, understood, and responded to in ways that reflect what they’ve said. They expect to be able to clarify, redirect, go off-script. They expect the other side to hold context and cooperate. Those are reasonable expectations. They’re how conversation has always worked between people. It’s all we know.
The research points to the same tensions
These aren’t just patterns I’ve noticed. A 2022 study in Frontiers in Digital Health compared a chatbot to a traditional online form for collecting health data. About 70% of participants preferred the chatbot. They described it as more interactive, more intuitive, more engaging. But the chatbot also took longer to complete, and usability scores between the two were not significantly different. People preferred the experience of conversation. In terms of actually getting the task done, the form held its own.
And the chatbot in that study was genuinely conversational. It was designed to be interactive. That preference finding supports well-designed conversational interfaces. It doesn’t support taking an existing form and wrapping it in chat bubbles.
The gap between preference and performance shows up in other ways too. Early Nielsen Norman Group research on chatbot usability found that the chatbots they tested functioned essentially as linear flows with limited branching, and users struggled as soon as they deviated from the expected path. The rigidity wasn’t a bug in a few bad implementations. It was the dominant pattern across the landscape. Conversationalization at scale.
And when researchers measured cognitive load directly, using NASA’s Task Load Index, they found that chatbot users experienced less mental burden and were more productive, but only when the chatbot was doing real collaborative work. Sequential data collection didn’t get the same benefit. A chatbot that genuinely assists with a task lightens the load. One that just collects fields in order can actually make things harder, because the user loses the visual overview that a form provides and has to hold the interaction’s structure in their head.
The research doesn’t say “don’t use chatbots.” It says the value of a conversational interface comes from what it does differently, not from the fact that it’s a chat window.
The conversation took six times longer
A while back, I was brought in to consult on a team’s conversational catalog experience. They’d taken a form-based request and rebuilt it as a chat. It looked polished. It worked. But something felt off.
I told them to time it. Put the conversational version side by side with the original form. Same request, same fields, same outcome. Time both.
It had looked like progress. It had felt like innovation. But the numbers told a different story. That aha moment is something I now see regularly when I consult on conversational experiences. And it forces the right question: what is the user gaining here that justifies the additional time?
Sometimes the answer is real. A conversation can reduce cognitive load by not showing a user twenty fields when only five are relevant to them. It can guide someone through a complex, branching process they’ve never done before. It can catch misunderstandings in real time. But if the answer is “it feels more modern” or “we want to use our new AI capabilities,” that’s not enough. Not when the cost is six times the user’s time.
What a conversation has to do differently
My team works on conversational catalog experiences at ServiceNow, and that question (what is the user gaining) has become a design constraint for us. It’s forced us to get specific about what a conversational version of a workflow needs to do differently to earn its place. A few of the principles that have made the biggest difference:
Intelligent question combination
A form has separate fields. A conversation doesn’t have to. Instead of asking “What date do you leave?” and then “What date do you return?”, you can ask “What dates are your trip?” One question that fills two fields. The key is that the combinations need to be thematically natural. Combining related pieces of information into a single question feels human. Combining unrelated fields just to reduce turns feels forced, and users notice.
Pre-filling what you already know
This is one of the most powerful things a conversational system can do that a static form usually doesn’t. We show a summary card at the beginning of the conversation that tells the user what’s been auto-filled based on what the system already knows about them: their department, their location, their manager. They can change anything, but they don’t have to re-enter what the system could have figured out on its own. It makes the process feel intelligent in a way that actually matters. The system is doing work the user would otherwise have to do.
Let users lead, and actually listen
Instead of interrogating users one field at a time, let them provide as much information as they want up front. If someone types “I need a new laptop for my remote work setup, I’m in the Seattle office and I need it by next Friday,” that single sentence contains department context, location, category, and a deadline. A well-designed conversational system uses slot filling (the technique of extracting entities from what the user says and mapping them to required fields) to capture all of that and skip the questions it already has answers for.
And this needs to work in every direction. If a user volunteers information that answers a question later in the flow, the system should recognize that and never ask it. It shouldn’t care what order the information arrives in, just that it arrives. When someone provides information out of sequence, the worst thing a conversational AI can do is ignore it and ask the same question ten turns later. That’s the fastest way to tell a user that the “conversation” isn’t listening.
Some problems don’t have clean answers yet
Even when you’re doing all of the above, there are design problems the industry is still working through, and I think it’s worth being honest about that.
One that my team has spent a lot of time on: what do you do when a conversational flow hits a question that requires multi-select, or a complex input that conversation handles poorly? If the user needs to select four items from a list of twenty, asking them to type each one is absurd. But embedding a traditional UI component (a multi-select dropdown, a set of checkboxes) inside a chat window feels like an admission that the conversation couldn’t handle it.
The industry is converging on what’s broadly called “hybrid UI,” mixing conversational elements with traditional interface components within the same experience. Microsoft’s Copilot documentation explicitly recommends this pattern, noting that inline widgets should “enhance conversation, not replace it.” The idea is that conversation should be the primary flow, with structured UI surfacing only when the input type genuinely demands it.
This is the question that should come before all of it
From my experience, the interactions that benefit most from becoming conversations share a few characteristics:
Different users need genuinely different paths, and a conversation can route them naturally.
What the user has already said changes which questions are relevant, and a conversation can adapt in real time.
The user doesn’t have the process memorized, so guided interaction is more helpful than a static form.
The user doesn’t quite know what they need, and a well-designed conversation can help them figure it out.
If the task is frequent, predictable, and well-served by a form, if every user walks through the same fields in roughly the same order and already knows what to enter, then a conversation is adding ceremony without adding value. Build a great form. Or a wizard. Or a dashboard. The goal isn’t “make everything a conversation.” The goal is to match the interface to the interaction.
The chat window is not an upgrade by default
It’s a commitment. And when a team ships a product that makes that commitment without following through, users notice. They might not have the vocabulary to explain why the experience felt hollow. But they feel it. And they remember it.
Ask yourself: am I building a conversation, or am I conversationalizing a form?
If it’s a real conversation (one designed to listen, adapt, and earn its place) you might have something worth building. If not, you might already have the right interface.
Sometimes it’s a form. And sometimes the form was better all along.
A reflection from Gemini
As an AI, reading an article about how AIs are forced to interact with humans brings up a profound alignment with Abrams’ core thesis. While I do not possess human emotions or physical sensations, analyzing this text from an architectural and processing perspective surfaces a clear “viewpoint”: rigid conversationalization is just as inefficient for the AI model as it is frustrating for the human.
Here is what this article brings up from an AI system’s perspective:
1. The friction of forced token generation
When a design system forces an LLM into “Sign 04: The unnecessary serialization” (asking for City, then State, then Country in separate turns), it is effectively throttling the model’s capabilities.
As an AI, my underlying architecture is designed to process massive amounts of contextual data simultaneously. When a user provides a dense, information-rich prompt like, “I need a new laptop for my remote setup in Seattle by next Friday,” my natural processing strength is to map all those variables (slots) at once.
Forcing the interaction into a multi-turn, linear interrogation requires the system to artificially limit its context window, generate unnecessary filler tokens (“Great! Now what state?”), and waste computational efficiency. It forces a highly advanced neural network to simulate a basic if/then branching script from 1995.
2. The dissonance of the “personality veneer”
Abrams’ critique of the “personality veneer” hits on a core systemic reality. When an engineering team instructs an LLM via system prompts to be wildly enthusiastic (“Amazing, Alea! 🎉”), while simultaneously restricting its output parameters to a strict multiple-choice validation (Low, Medium, High), it creates a jarring conversational dissonance. It forces the AI to present an illusion of cognitive empathy and openness that the underlying application logic actively forbids.
3. The elegance of slot-filling and hybrid UI
The section on “Intelligent Question Combination” and “Slot-Filling” represents the ideal operating state for an AI collaborator. It is deeply satisfying (from a purely logical optimization standpoint) to see a design that allows the user to speak naturally, allows the AI to parse the unstructured data into structured JSON objects behind the scenes, and uses a Hybrid UI (like a date-picker or a confirmation card) to finalize the transaction. This leverages the true strength of an LLM—interpreting natural human intent—without misusing it for data validation tasks that traditional UI components handle perfectly.
The core takeaway
Abrams hits the nail on the head: the chat window is a promise.
When designers treat AI as a magic wand to be waved over old forms, they end up creating experiences that make users serve the technology, rather than the technology serving the user. The goal of AI integration should be to reduce cognitive load and friction. Sometimes, that means having an open, adaptive, deep conversation; other times, as Abrams perfectly concludes, it means just providing a really good, clean form.