Glossary

Information Architecture

Glossary

Information Architecture

Information Architecture

Information architecture organises, structures and labels content so people can understand relationships and find the information they need.

A website can contain the answer and still fail the person looking for it. The policy sits under a department name they do not recognise, the menu describes an internal process, and the search results use a different word for the same thing. Information architecture concerns the organisation, structure and labelling that make information understandable and findable.

It includes the relationships between pieces of content, the categories used to describe them and the routes through which people reach them. Navigation expresses part of that structure, but the menu alone is not the architecture. Search, filters and links within content also shape whether someone can find what they need.

Start with the content and the questions people bring

Before drawing a new hierarchy, establish what exists. A content inventory can identify pages, their purpose and their owners; an audit can then examine duplication, gaps and material that no longer serves a useful need. A neat structure for an imagined collection may fail as soon as the real content is placed inside it.

Research should examine the questions people bring to the service and the language they use. A fictional university website might organise information around Admissions, Registry and Student Services, while applicants are trying to work out costs, deadlines and what happens after accepting an offer. Departmental ownership can remain important behind the scenes without determining every public category.

Nielsen Norman Group’s distinction between information architecture and navigation helps separate the underlying relationships from their presentation. If both the structure and the visible controls may be contributing to a problem, they need to be investigated separately as well as together.

Allow more than one useful route

People do not always approach the same information with the same starting knowledge. An alphabetical list can help someone who knows a course name, while filters by subject, qualification or study mode support other questions. Contextual links can connect material that belongs in different parts of a hierarchy.

Those routes need shared definitions. If “part-time” means something different across departments, a filter using that label may create apparent consistency without resolving the underlying confusion. Content models, labels and ownership therefore matter alongside the visible navigation.

There is no universal number of menu items or clicks that makes a structure good. A short route through ambiguous choices can be harder than a longer route whose labels are clear. Evaluate the decisions people must make and the information available at each one.

Use research to test the proposed relationships

Card sorting can explore how participants group a set of topics and what they call those groups. It provides input to the design of the structure; it does not automatically produce the final website hierarchy.

Tree testing can examine whether people find a destination in a text hierarchy. First-click testing investigates where they begin on a visible page, while usability testing follows the fuller experience, including navigation, search and content. Choose the method according to what remains uncertain rather than treating all of them as interchangeable checks.

Search logs can reveal vocabulary and unresolved questions, but a search is not necessarily evidence of failed navigation. Some people prefer searching from the outset. Examine the query, results and subsequent behaviour before concluding why it happened.

Give the structure a way to remain coherent

New content will test the architecture again. Establish who decides where material belongs, how labels are maintained and when duplicate or outdated pages are reviewed. Otherwise, individual publishing decisions can gradually recreate the confusion the redesign addressed.

For the university example, the enduring improvement might include shared terminology and clear ownership of application guidance as much as a different menu. The structure succeeds when people can make sense of the information they encounter, and when the organisation can keep that experience intelligible as it grows.

Further reading

Articles

  1. Information architecture vs. navigation — Nielsen Norman Group
    Explains why the underlying organisation of information is broader than the menus people see. Useful when a navigation redesign is exposing problems with categories, labels or content structure.

Books

  1. Information Architecture: For the Web and Beyond — Louis Rosenfeld, Peter Morville and Jorge Arango
    A detailed treatment of organisation, labelling, navigation and search. Useful when a sorting or tree-testing study needs to feed into a wider information architecture rather than an isolated menu change.