Information architecture before interface

Information architecture is the least photogenic work in product design. It produces no screen, demos badly, and is almost impossible to show a stakeholder in a way that earns applause. So it gets skipped, and the interface work starts — which is the point at which the project quietly becomes more expensive.

IA is deciding what the things are, what they are called, and how they relate. Interface is deciding how those things are shown. Doing the second before the first means designing screens for a structure that has not been agreed, and every later disagreement about the structure invalidates screens.

What IA debt looks like from the outside

You rarely hear "the information architecture is wrong". You hear these instead:

• The navigation has a "More". The clearest signal there is. It means the model stopped fitting, and rather than revisit it somebody added a drawer.
• Two names for one thing. The product says "project", the invoice says "job", support says "account". Each was right locally; together they mean the concept was never pinned down.
• Settings has become a junk drawer. Things land there when nobody can say what they belong to — which is an unanswered IA question wearing a page.
• Search is being used as navigation. When people search for things they could in principle browse to, browsing has failed.
• The same object is reachable by three routes that look unrelated, so nobody can describe where it "is".
• New features have nowhere obvious to go. Every addition triggers a layout argument, because there is no rule about what is a sibling and what is a child.

What the work actually is

Four decisions, none of which require a visual tool:

1. 01Naming. One word per concept, taken from the language the people using it already speak rather than from the database schema. This is most of the work and it is usually treated as copywriting done later.
2. 02Grouping. What belongs with what — according to how the work is done, not how the company is organised. Products that mirror the org chart are the classic failure here, because the customer does not have your org chart.
3. 03Hierarchy. What contains what. Whether a thing is a sibling or a child is the decision that determines the whole navigation, and it is usually made by accident, in a hurry, once.
4. 04Relationships. What links to what without containing it. Getting this wrong forces duplication: the same object listed in three places because nobody could decide where it lives.

The test that settles arguments

There is one question that resolves most IA disputes without appeal to taste: can someone predict where a thing is before they look for it?

Not find it — predict it. Findability can be bought with search and good labels on a bad structure. Predictability only comes from the structure matching the model in the user's head, and when it does, the interface gets simpler almost on its own: fewer tabs, fewer explanatory tooltips, fewer empty states apologising for where you have ended up.

If people can find things but not predict where they are, you have a search problem hiding a structure problem.

The test is cheap to run badly and valuable to run honestly: describe a thing in plain words and ask where someone would expect it, without showing them the product. Disagreement in the answers is the finding.

Where the decision is visible

IA is invisible when it is right, which makes it hard to point at. It is easiest to see in products whose content is genuinely varied, because that is where a weak structure cannot hide.

Gavroche is a client project — UX and UI design for an online shop — and a shop is an IA problem before it is a visual one: what a category is, what a product variant is, and what a customer is expected to have decided before they can choose.

Pluto is a concept project, self-initiated and not publicly released. Its pages show flows and interface decisions rather than measured outcomes, which is exactly the limit of what a concept can demonstrate — the reasoning on that distinction is in Concept, published, and client work.

Why it gets skipped, and what to do about it

Because it produces nothing to look at. A week of IA work ends with a document and some renamed concepts; a week of interface work ends with screens somebody can react to. Under pressure to show progress, the second always wins.

The practical answer is not to argue for more time up front but to make the structure visible early in the cheapest form available: a list of the objects, their names, and what contains what. One page. If the team cannot agree on that page, they are not ready to review screens — and finding that out costs an afternoon rather than a sprint.

If your navigation has grown a "More" and you are deciding what to do about it, tell us what you are building.