Ask a UX team to show you the sitemap for their website and they'll pull it up in seconds. Ask the same team to show you the "map" of their chatbot and you'll get a shrug, a Notion doc with forty half-finished intents, or a shrug followed by "the model just figures it out." That gap is why so many chatbots feel lost: nobody drew the floor plan before construction started.
Information architecture used to mean organizing pages, labels, and navigation so people could find things on a site. Conversational products need the same discipline, just applied to a structure you can't see: intents, turns, and context. Skip it and you get a bot that answers the first question well and falls apart by the third.
Your Chatbot Already Has an IA, It's Just Invisible
Every chatbot has an implicit architecture whether anyone designed it or not. There's a set of things the bot can do, a way it decides which thing you're asking for, and a path it follows once it's decided. On a website, that structure is a sitemap and a nav bar. In a chatbot, it's an intent taxonomy and a dialogue manager, and if nobody drew it out, the model is improvising it from training data and prompt scaffolding.
That improvisation is where trouble starts. Research on conversational product evaluation points to four things that separate a bot people trust from one they abandon: whether it's clear what the bot can actually do (capability transparency), what happens when it gets something wrong (recovery patterns), how confident it seems about its own answers, and whether the whole thing works for people using assistive tech. Three of those four are architecture problems, not model problems. You can have the best language model available and still fail all three if nobody designed the structure underneath it.
The fix isn't exotic. It's the same exercise IA practitioners already know: card-sort the things users actually come to your bot for, group them into a hierarchy, and write down the paths between groups. The difference is that instead of a sitemap with pages, you end up with a taxonomy of intents and the transitions allowed between them.
Intent Taxonomies Are Sitemaps for Conversation
An intent taxonomy is the closest thing conversational design has to a sitemap, and it deserves the same rigor. Microsoft's approach with Copilot Chat is a useful reference: they built a two-level hierarchy, with top-level categories and sub-intents underneath, and populated it two ways at once. Bottom-up, by mining real conversation logs to see what people actually asked for. Top-down, by having product teams curate the categories that mattered for the business. Neither approach alone was enough. Pure bottom-up taxonomies mirror what happened, not what should happen. Pure top-down taxonomies miss the weird, real ways people phrase requests.
The most common failure at this layer isn't a missing intent, it's overlap. When two categories share vocabulary and the boundary between them isn't crisp, classification accuracy is capped no matter how good the underlying model is. "Cancel my order" and "return my order" sound almost identical to a classifier if your taxonomy doesn't force a clean split with clear business rules behind it. This is pure IA work: same discipline as untangling two nav categories that both claim "Resources."
Treat the taxonomy as a living document, not a one-time deliverable. Review transcripts monthly, look for questions the bot mis-routed, and check whether new intents are forming that don't fit anywhere. A taxonomy that hasn't changed in six months isn't stable, it's stale.
The Context Window Is Not the Same as Memory
This is where most teams get the mental model wrong, and it costs them. A context window is not memory. It's short-term working space, and it has a hard limit. Memory, if your product has it, is a separate system that decides what gets pulled back into that window later. Conflating the two is how you end up with a bot that "forgot" something it technically still has stored somewhere, just not where it can currently see it.
Good conversational IA treats the context window like prime real estate on a homepage: valuable, limited, and worth fighting over. Every turn, something has to earn its place in that window. Some information belongs there for the whole session, like the user's stated goal or account context. Some belongs there for a turn or two and then should get summarized down to a line instead of carried verbatim. Some should be dropped entirely once it's served its purpose. Deciding which is which, turn by turn, is an architecture decision, and right now most teams are letting it happen by default rather than by design.
The payoff for getting this right is measurable. Systems that maintain contextual memory well see meaningfully better accuracy and user satisfaction compared to stateless ones, because the bot stops asking users to repeat themselves. The payoff for getting it wrong shows up just as clearly: a large share of users report that their chatbot fails to understand intent or resolve their issue at all, and a big chunk of that traces back to the bot losing the thread mid-conversation rather than failing to understand a single message in isolation.
Wayfinding When the User Gets Lost
Websites have breadcrumbs, back buttons, and search bars for the moment someone takes a wrong turn. Chatbots need the conversational equivalent, and most don't have one. When a user asks something the bot can't confidently classify, what happens next is entirely an IA decision: does it guess, does it ask a clarifying question, does it offer a menu of likely intents, or does it hand off to a human?
Well-designed recovery loops give the user a way out that doesn't require starting over. That might mean quick-reply buttons that let someone pivot without retyping their whole question, a citation that lets them verify a factual claim themselves, or a clean handoff to a person that carries the conversation context along instead of dropping it at the door. The interfaces that handle this best don't rely on chat alone. They blend free text with structured elements like buttons and cards, so users can choose whichever is faster for them in the moment. That's a hybrid UI decision, and it belongs in the same architecture conversation as the taxonomy and the context strategy, not bolted on afterward.
The cost of skipping this is steep and well documented: a majority of users abandon a chatbot interaction after getting stuck in a loop, and roughly half walk away entirely after a single bad experience. Those aren't model failures. They're the conversational equivalent of a 404 page with no search bar and no way back to the homepage.
Draw the Map Before You Build the Bot
None of this requires new tools. It requires treating a chatbot the way you'd treat any other product with a structure users need to navigate: map the intents, decide what belongs in working memory versus long-term memory, and design the recovery paths before launch instead of patching them in after support tickets pile up. The model handles language. The architecture is still your job.
👨💻 Connect With Me
Rohit Raghuvansh
💡 UX Thinker · AI Builder · Making complex tech human-centered
Connect & Follow
📢 Found This Article Helpful?
If this article added value to your learning journey:
✅ Share it with your network ✅ Bookmark it for future reference ✅ Follow for more
Keep Learning. Keep Building. Keep Growing. 🚀
Top comments (0)