Information Architecture
Information architecture is how a product's content, records and labels are organised and named, so people can find what they need and predict where things live. In UX work it covers the things a product holds, how they relate, what they are called and the routes between them.
- Product design
- Workflow software
Information architecture examples from deal and staffing software
It matters when people cannot predict where something lives. Look at how the records are structured as well as at the navigation. That counts most when the same work crosses screens, roles and spreadsheets.
In workflow software it reaches past navigation. A staffing candidate, for example, can belong to pools, jobs and organisations. Those relationships need to be clear before a team decides where links or screens should go.
Workflow design adds roles, rules, states and handoffs. A sitemap is one way to draw information architecture, among several.
Explore Information Architecture and Workflow Design or see the Scissors staffing software, organised around its clients, candidates and jobs.
Information architecture helps when a team cannot improve navigation until it is clear what the product contains. In Dealpath, checking whether a listing already belonged to a deal changed the creation path. The surrounding actions stayed largely as they were. The structural choice came before the screen change.
In Scissors, one client organisation spans many jobs, one candidate may appear on several shortlists, and talent pools get reused whenever new work comes in. Tcules modelled those things and the links between them, then redesigned four workflows on that one structure.
Tcules' Information Architecture and Workflow Design work treats records, relationships, roles, states and routes through the product together.
How information architecture is worked out in UX
The work moves from what the product holds to how people reach it.
- List what the product holds. Records, content types and the actions people take on them, drawn from the product and from how people work today.
- Map how they relate. Which things belong to which, which recur across workflows, and which roles can see or change each one.
- Test the names. Card sorts and tree tests show whether people group and label things the way the team does.
- Plan the routes. Navigation, search and links sit on top of the structure, so each record has one clear home.
- Walk real tasks through it. The main jobs are traced through the structure to find dead ends and duplicates before screens are designed.
Information architecture vs navigation and sitemaps
| Information architecture | Navigation | Sitemap |
|---|---|---|
Defines records, relationships, roles, states and meaningful groupings | Provides routes and wayfinding through that structure | Draws the pages or screens and how they nest |
Can reveal that the product's own model is unclear | Can be redesigned well only once the underlying distinctions are understood | Shows the hierarchy at one moment, usually as a diagram |
Reaches beyond menus and page hierarchy | Is one visible expression of the architecture | Is one way to document the architecture, among several |
Questions about information architecture
Is information architecture the same as a sitemap?
A sitemap is one drawing of information architecture: the pages or screens and how they nest. The architecture also covers the records behind those screens, how they relate, what they are called and who can reach them. Two products can share a sitemap and still behave very differently.
How is information architecture different from UX design?
Information architecture is one part of UX design. It works out what the product holds, how that is organised and what each thing is called. The rest of UX design shapes the flows, screens and interactions that sit on top of that structure.
When should a product team revisit its information architecture?
Revisit it when people keep asking where something lives, when a new module has no obvious home, or when two teams use different names for the same record. Each is a sign the structure has fallen behind the product. A UX & Product Audit can show whether the cause is structural or local.
Related terms, and help organising a product's structure
Structure matters most once several roles need the same record to mean the same thing. It now has a second audience too: AI assistants and agents that search, summarise or act inside a product rely on the same records and relationships people do. User journey mapping follows a person's experience across stages, and UX debt often begins as a structure the product has outgrown.
Tcules works out records, relationships, roles and routes through Information Architecture and Workflow Design, before the screens are drawn.
Clarify your product structure
Talk to Tcules about the objects, relationships, labels and routes that shape how people use your product.