Information Architecture Is Not Menu Design

Information architecture is often reduced to a sitemap exercise.

Home. Products. Settings. Profile. Reports.

Then the navigation is cleaned up and the work is called complete.

Navigation is part of information architecture, but it is not the architecture itself. The deeper problem is whether the user can understand what things are, how they relate and which information matters in the current context.

Model the entities before the menu

If the core entities are unclear, cleaning the navigation is cosmetic.

In Ordovia, for example, you have to know what a task, planned time, project, ritual, note and daily context actually mean and how they relate. If the same concept appears in two places with different semantics, moving a menu item does not repair the model.

Bookcrumb is not primarily a list of books

A recommendation product can easily become a catalogue interface. But the useful information model is closer to:

Reader Profile + current Mood / Theme / Pace + Reading History → Recommendation Context → Reading Route → Books / Notes / Memory.

The user does not need every variable exposed as a dashboard. The system still needs to understand the role of those variables.

Good information architecture does not mirror the backend into navigation. It moves the right context to the right decision point.

Lumoria turns information density into a route decision

Travel planning has abundant input: location, interests, duration, mobility, weather, distance and opening hours.

Showing all of them as independent filters can produce a powerful interface and still leave the user asking, “What should I do today?”

The stronger model starts from actual context — for example, where the user is really staying rather than an abstract city centre — and then turns the relevant signals into one route decision.

That is information architecture operating inside the decision flow.

Five layers I inspect

1. Vocabulary

Does the same concept have the same name everywhere?

2. Entity model

What objects actually exist in the product?

3. Relationships

How are those objects connected?

4. Context

Which relationship matters at this moment?

5. Navigation and retrieval

How does the user reach or recover the information?

Teams often start at layer five and then wonder why the menu keeps changing. The instability usually comes from the first four layers.

Search problems can be classification problems

When users cannot find something, the default reaction is stronger search: fuzzy matching, new filters, tags, sorting.

Sometimes that is correct. Sometimes you are building a better search engine for a poorly classified system.

I first ask what the user calls the thing, what the system calls it, whether the entity belongs in that location, whether it has multiple contexts and whether the retrieval path reflects the real domain relationship.

A simple surface can sit on top of a rich model

Good information architecture does not always create more navigation. It often creates less.

The backend can have a rich relationship graph. A context engine can combine many signals. The user can still see only the next useful decision.

The goal is not to hide complexity. It is to resolve complexity at the correct layer.

A clean navbar cannot make a badly classified product understandable. Information architecture starts with meaning, relationships and context; navigation is only its visible edge.