Good AI experiences start with information architecture

An AI answer box can make a website feel simpler. A visitor asks a question instead of working through navigation, and the system responds in familiar language. That is an appealing interaction. It also makes the quality of the information underneath the interface much more important.

If the site has conflicting descriptions, unclear ownership, and several pages that appear to answer the same question, a conversational layer inherits those problems. It may make the inconsistency less visible until someone relies on the answer. I would rather resolve that structure before asking AI to explain it.

Information architecture is the work of organizing information so people can find it and understand how it fits together. For me, it includes the decisions behind page names, content relationships, navigation, and the boundary between one subject and another. Those decisions still matter when the front door becomes a question.

Start with the questions people actually bring

My preserved Hoopes Vision website brings procedures, doctors, technology, and patient resources into a connected experience. One important design decision was to give visitors starting points based on familiar goals. Someone can begin with reducing their reliance on glasses without already knowing the name of a procedure.

That distinction is useful far beyond healthcare. A university visitor may know what they want to study without knowing which department owns the program. A contractor may know a customer has accepted an estimate without knowing what the software calls the next workflow. The site's internal vocabulary should not become an entrance exam.

If I were adding AI to one of those experiences, I would begin with the same questions. What is the person trying to decide? What information is required for that decision? Which terms do they understand? Where should the system stop and direct them to a person? These questions define the answer experience before a model is selected.

Give each important fact a dependable home

A content inventory often exposes decisions that a sitemap alone misses. A page may be listed in the navigation but contain information copied from another page. An old document may remain searchable after its replacement has been published. A staff member may know which version is current while the content itself gives no useful signal.

I would document a primary home for each important subject. That does not mean a fact can appear only once. A brief description can appear in a directory and link to the complete page. The relationship should be deliberate, and the team should know which source controls the detail when something changes.

For a hypothetical procedure directory, the model could distinguish the procedure, the conditions it addresses, the relevant educational resources, and the next available action. That is more useful than treating every page as an unrelated block of prose. The relationships help editors maintain the site, help visitors move through it, and give an answer system a clearer set of boundaries.

Content ownership belongs beside that structure. A description that requires specialist review should have a responsible reviewer and a clear update process. AI does not remove that responsibility. It increases the number of ways that description may be encountered.

A conversation should preserve useful distinctions

Traditional websites communicate structure through headings, breadcrumbs, and links. A generated answer can compress those cues into a paragraph. That can save effort, but it can also flatten differences that matter.

Consider a university website with a college, a department, a degree, and an event series. A person might mention all of them in one question, but they are different kinds of things. They have different owners and change at different speeds. An answer that casually merges them can sound understandable while sending someone to the wrong next step.

The BYU Humanities project involved content planning for programs, people, news, research, events, and resources. Our annotated wireframes documented how those areas related across page types and screen sizes. The visual design and WordPress implementation were shared team work. The underlying lesson is that content relationships need to survive beyond the homepage.

For an AI layer, I would carry those relationships into retrieval and answer review. A directory answer should point to the right person record. A program answer should use the program's current source. A question about an event should not quietly reuse a historical announcement as if it described a future date.

Test the content without the model first

Before testing a generated answer, I would try to answer a set of representative questions using only the approved sources. This is a practical way to discover whether the problem is retrieval, presentation, or missing information.

If a team cannot agree on the answer while looking directly at the content, an AI feature cannot settle the disagreement responsibly. Someone needs to clarify the policy or rewrite the source. If the answer exists but requires opening seven pages, there may be a content relationship worth improving. If the answer is intentionally unavailable, the interface needs a useful way to explain that limit.

I would include awkward questions in this exercise. What if the visitor uses an old product name? What if two pages have similar titles? What if the requested answer depends on an individual situation? These are ordinary content problems that become interaction problems when the system is expected to answer immediately.

The output can be modest: a question, the approved source, an expected answer boundary, and a next step. That record gives designers and engineers something concrete to review together.

Make the maintenance path part of the experience

An answer system creates an ongoing publishing responsibility. Someone must know how new content becomes available, how retired content is removed, and how corrections reach the experience. I would make those paths visible in the product plan rather than treating them as an implementation detail.

For editors, that might mean structured fields and a simple review state. For reviewers, it might mean a list of answers affected by a source change. For users, it might mean a link to the authoritative page and a clear way to report an issue. These mechanisms have different audiences, but they support the same goal: information that can be corrected without confusion.

This is also where navigation remains valuable. A conversational interface can help people discover an answer, while a well-organized site lets them inspect the surrounding context. I would keep both routes useful. A visitor should be able to move from a short answer into the complete resource without feeling that they have entered a different product.

Better structure makes the next decision easier

I see information architecture as preparation for change. Clear content types, understandable labels, and deliberate relationships give a team more options. They can improve search, redesign a page, publish a new resource, or explore an AI feature without repeatedly rediscovering what the information means.

That work is less dramatic than adding a chat window. It is also closer to the reason someone visited in the first place. People need a dependable answer and a sensible next step. The interface earns its place by helping them get there.

When I evaluate an AI idea for a content-heavy experience, my first question is therefore about the source: could a person understand and maintain this information with confidence? If the answer is unclear, I would start there. A stronger information foundation improves the current website while giving any future AI experience something worth working with.