Information architecture (IA)

Why information architecture matters

Users never see your IA, but they feel it. If billing lives under Settings, invoices under Account and payment methods under Workspace, people will open three menus and then email support.

Nielsen Norman Group uses a nice analogy: you can't see a skeleton, but it decides what the animal can do. A weak structure limits every screen built on top of it, however polished those screens look.

What information architecture work involves

It starts with a content inventory, a list of everything the product or site holds. A content audit then checks what's useful, accurate and current. From there you group content in ways that match how users think and agree consistent names for things.

The output lives in spreadsheets and diagrams, usually a site map or hierarchy, not in wireframes. That separation is useful, because it lets you argue about structure before anyone argues about visual design.

Taxonomy, labels and metadata

Three pieces of IA work decide whether the structure holds up as content grows.

Labels are the names people see: menu items, section titles, button text. They should be the words your customers use. If support tickets say "invoices" and the menu says "Billing documents", people will search instead of clicking.

A taxonomy is the controlled list of terms used to classify content. Nielsen Norman Group defines it as "a closed list of acceptable terms that are arranged hierarchically and are used to describe and classify content". It stays behind the scenes, and it is usually broader than the navigation.

Metadata is what gets attached to each piece of content: its topic, its type, its audience, its date. This is what makes the useful features possible. NN/g notes that filters are built on faceted taxonomies, that related-content modules pull items from the same category, and that search can use the taxonomy to suggest related terms.

None of this needs special software at the start. A spreadsheet with one row per page and one column per attribute is enough to see where the gaps are.

Information architecture vs navigation design

IA is the underlying structure. Navigation is the set of interface components that let people move through it: menus, tabs, breadcrumbs, filters, footers and related links. Navigation design decides which components to use, where they go and how much people will rely on each.

Define the IA before you choose the navigation. Nielsen Norman Group gives the example of a team that picks an inverted-L layout because it looks good. That layout suits sites up to four levels deep, and then their content turns out to go deeper. The IA doesn't need to be final before wireframing, but a first pass is needed.

Information architecture vs a sitemap

A sitemap is a picture of the structure. It shows the pages and how they nest. It is one way to document IA, and often the most useful one to put in front of a team.

It is not the whole IA. The sitemap does not show the naming rules, the taxonomy, the metadata on each page or the reasons a section sits where it does. Two sites can have the same sitemap and feel very different to use, because one labels things in the customer's words and the other does not.

Treat the sitemap as the summary, and keep the inventory and the naming decisions next to it.

Information architecture for products and for websites

The work is the same in principle and different in what it organises.

On a website, IA organises content: pages, articles, case studies, documentation. The questions are about audiences and topics. Who is this section for, what would they call it, and what do they need next?

In a product, IA organises objects and actions: customers, invoices, projects, settings, and what each role is allowed to do with them. The questions are about tasks. What does someone do every day, what do they do once a month, and what should only an admin see?

A common mistake is to structure a product like the company's org chart, or a website like the product's menu. Both make sense to the people who built them and to nobody else.

How to test information architecture

Card sorting asks participants to group labelled cards in whatever way makes sense to them. It shows you how users expect content to be organised, so it's best before or while you design the structure.

Tree testing works the other way round. You give people a text-only version of your proposed hierarchy and ask them to find specific things. It shows whether your labels and categories work without visual design to prop them up.

Both are forms of usability testing aimed at structure, and both are cheap to run before any screen is designed.

How Gr8r approaches information architecture

On website and product projects, we map the content and agree the structure with you before we draw a single screen. We aim to label things in the words your customers use, not internal team names.

In a UX audit, we flag findability problems in the flows we review. Common ones are features hidden under the wrong heading and two menu items that mean the same thing.

For websites this is the first step of website design and development. For products it is part of product design. Our startup website launch checklist covers the structure checks to run before a site goes live, and a UX audit is how findability problems in a live product usually come to light.