Information architecture (IA)

In short

• IA decides what goes where and what it is called, before anything is styled.
• Good labels use the words your users use, not your internal team's names.
• Card sorting shows how people group things. Tree testing checks whether they can find them.
• Weak IA is expensive to fix later because navigation, URLs, and content all depend on it.

Also called: IA, Site structure, Navigation design, Content structure.

What information architecture covers

Every product has an information architecture, whether anyone designed it or not. It is the structure underneath the screens: which sections exist, what each one contains, what the menu items are called, and how one area links to another. When it works, people find things without thinking about it. When it does not, they search, guess, and give up.

The field has a long history in web design. The book often called the polar bear book, Information Architecture for the World Wide Web by Louis Rosenfeld and Peter Morville, first published in 1998, described four systems that still frame the work today.

IA for websites and for apps

On a marketing site, IA mostly means the sitemap: the pages, the menu, the footer, and the URL structure. On an app, it means the main areas of the product, how objects relate to each other, and how a person moves between them. A project management tool has to decide whether tasks live inside projects, inside teams, or both. That is an IA decision, and it shapes the database, the navigation, and the user flows built on top. In a Choie build, that hierarchy is decided in the first two weeks along with the flows, as part of the product design work, because so much rests on it.

How to design and test it

IA work is mostly listening to how people think about the subject, then making a structure that matches. A few methods do most of the work.

• Content inventory. List everything the product or site has to hold, so the structure is built around real content and not guesses.
• Card sorting. People group cards with topic names in a way that makes sense to them. In an open sort they also name the groups, which tells you their vocabulary.
• Tree testing. People are given a text-only version of the menu and asked where they would look for something. It tests the structure without any visual design getting in the way.
• Search logs and support questions. What people type into search and ask support shows what they cannot find.

Choie's prototype week does not include recruiting participants or formal testing. What it delivers is a coded prototype of one workflow that the client can put in front of their own users afterward, to see whether people find their way.

When IA matters most

A small first release with one main workflow needs only a light structure. IA becomes important when a product grows past a handful of sections, when a site has dozens of pages, or when two user types need different routes through the same product. It is also the first thing to look at when people say a product is confusing, which is why it is part of most UX audits.

Clear structure helps machines too. Search engines and AI assistants read headings, URLs, and internal links to work out what a site is about, so sensible IA supports answer engine optimization as well as people.

Common mistakes

• Mirroring the org chart. Menus organized by internal department instead of by what customers are trying to do.
• Clever labels. Brand names for sections that nobody outside the company understands.
• A catch-all section. A menu item called More or Resources that slowly fills with everything that did not fit anywhere else.
• Changing URLs without redirects. Restructuring a site and breaking every link that pointed to the old pages.
• Skipping testing. A structure that seems obvious to the team can fail a simple tree test with real users.

During a Choie build, a new live link goes out every Friday for the client to use rather than review, so a label that only made sense to the team shows up early. See how a project runs.

Common questions