Tested With Users
Card sorting and tree testing, before anything is built on it.
Information Architecture Services
Information Architecture Services Organised Around How People Look
Most navigation reflects how the organisation thinks about itself: divisions, product lines, internal categories. Visitors do not know any of that. Information architecture services reorganise around how people actually look for things — and test that with real users rather than agreeing it in a room.
We Test the Structure Before Building It
A structure everyone in the meeting understood is not evidence that anyone outside it will.
Their Words, Not Yours
Labels people recognise rather than internal terminology.
Depth Controlled
Every extra level costs a share of the people navigating it.
Search Considered
Structure that produces findable URLs, not only usable menus.
Scales
Room for growth without a reorganisation every year.
How a structure is tested before it is built
Information architecture is testable before anything is designed, which is what makes it worth doing separately. These checks establish whether people can find things in the proposed structure while changing it is still cheap.
Findability rateWhether users locate a given item in the proposed structure
First-click accuracyWhether the first choice people make leads toward the right place
Label comprehensionWhether category names mean the same thing to users as to the team
Card sort agreementHow consistently users group the same items
Depth versus breadthHow many levels a user must pass through to reach common items
Orphaned contentAnything reachable only by search or a direct link
Duplicate placementItems appearing in more than one branch without a rule for it
Search dependencyHow much of the structure only works if search does
Growth headroomWhether the structure survives the next year of additions
URL implicationsWhether the structure forces changes to addresses that already exist
Navigation loadWhether the top level fits in a menu people can scan
Cross-linking needsWhere relationships exist that a hierarchy cannot express
The URL row matters more than it looks. A structural change that alters existing addresses has search consequences well beyond navigation, so any proposal affecting live URLs should be evaluated as a migration rather than as a design decision.
Information Architecture, Explained
What Does IA Decide?
Four things, and all four are testable before a line of code.
Discuss Your Structure →- 1
Grouping
What belongs together, from the visitor's point of view.
- 2
Labelling
What each group is called, in language people recognise.
- 3
Depth
How many levels, which directly affects how many people arrive.
- 4
Cross-References
Where something legitimately belongs in more than one place.
What IA Work Covers
Research, structure and validation before anything is built.
Restructuring changes URLs — SEO migration covers protecting them. Where restructuring changes URLs it becomes an SEO migration; turning the structure into an interface is UI design.
How We Build Information Architecture
Research, propose, test, then build. The testing step is what makes it evidence.
Inventory the Content
Everything that has to be placed somewhere.
Research the Grouping
Card sorting with people outside the organisation.
Propose a Structure
Built from what the research showed.
Tree Test It
Can people find things in it, before anything is built.
Map the URLs
With redirects where paths change.
What makes structure the actual problem
Information architecture work is warranted when people cannot find things, not when a menu looks untidy. These are the situations where structure is genuinely the constraint.
Sites that have grown without a plan
Where sections were added as needed and the structure now reflects the order things were built rather than how anyone looks for them. This is the most common case and usually the most improvable.
Large catalogues and content libraries
Where the volume makes browsing impractical and the real work is in categorisation, filtering and search. The structure has to match how users describe things rather than how the business files them.
Products adding a second line
Where navigation built for one offering has to accommodate something the original structure never anticipated. Doing this before the interface work avoids designing the same screens twice.
Organisations whose site mirrors their org chart
A recognisable pattern where departments own sections and users have to know the internal structure to find anything. Fixing it is partly political, because it means someone loses a section they consider theirs.
Sites where search carries the structure
Where analytics show most people search immediately rather than browsing. That is evidence the structure has stopped working, and improving search alone treats the symptom while the navigation continues to fail everyone who tries it.
Testing
Why Tree Testing Is the Cheapest Insurance Available
It validates a structure before anything is built on it, and it takes days.
What is tree testing?
Participants are given the proposed structure as a bare list of labels — no design, no visuals — and asked where they would look for specific things.
It measures whether the structure works, isolated from whether the interface is attractive, which is the only way to test the two separately.
It runs remotely, needs no build, and produces a completion rate per task. A structure that fails it will fail after launch too, only far more expensively.
Why does internal language get in?
Because everyone specifying the navigation uses it daily and has forgotten it is specialised. Product names, division names, internal category terms — all obvious to the people choosing them.
Visitors search using ordinary words for their problem. A menu labelled with your taxonomy asks them to translate, and most do not.
The fix is testing labels with people outside the organisation, which surfaces the problem within an afternoon and is skipped almost universally.
Structure fails when it describes the organisation
The most common architectural failure is a structure built from how a business is organised internally — by department, by product line, by the team that owns each area. It is legible to everyone inside the company and opaque to everyone outside it, because users do not know the org chart and have no reason to.
Users look for things by what they are trying to do or what they need, and those categories rarely map onto departmental boundaries. Someone with a billing question does not know whether that belongs to finance, support or account management, and a structure organised that way requires them to guess correctly before they can proceed.
Correcting it is straightforward to describe and often difficult to implement, because sections correspond to internal ownership and restructuring means someone gives something up. That is why this work benefits from being evidenced — card sorting and tree testing produce data about how users actually group things, which is harder to argue with than a competing opinion.
Depth, breadth and the myth of three clicks
A persistent rule of thumb holds that anything should be reachable within three clicks. It is not supported by the evidence and it produces bad structures, because it pushes teams toward flat hierarchies with enormous top levels that are harder to scan than a deeper structure with clear labels.
What actually determines success is confidence at each step. Users will happily click five times if every choice is obvious, and they will abandon after two if they are guessing. The relevant measure is first-click accuracy — whether the initial choice leads toward the right area — because users who start down the wrong branch rarely recover.
This shifts the design effort from counting levels to writing labels. A clear, unambiguous category name does more for findability than removing a level of hierarchy, and it is usually cheaper to change.
Testing structure before building it
Information architecture is unusual among design deliverables in that it can be validated before anything is designed. Two inexpensive methods do most of the work, and both can be run in days rather than weeks.
Card sorting asks participants to group items themselves, which reveals the categories that exist in users’ minds rather than the ones the team assumed. Tree testing does the reverse: it presents a proposed structure as text only and asks people to locate specific items, which isolates the structure from any visual design that might otherwise compensate for it.
Running both before interface work begins is what makes structural problems cheap to fix. Discovering that a category name is misread is a text change at this stage and a rebuild after the site is built — which is why this belongs before wireframing rather than alongside it.
Questions, answered.
Information architecture services organise content and navigation around how people look for things — grouping, labelling, depth and cross-references — validated with card sorting and tree testing.
Test it. Tree testing gives a completion rate per task using nothing but the labels, runs remotely, needs no build, and takes days rather than weeks.
As shallow as the content allows. Every additional level costs a share of the people navigating it, so depth should be a deliberate trade rather than a consequence of the content model.
Because visitors do not know them. Internal terminology is invisible to the people who use it daily and requires translation from everyone else, and most will not bother.
Yes, where URLs change. A restructure without a complete redirect map loses what those URLs earned — see SEO migration.
Architecture is the underlying structure — what exists, how it is grouped, and how the groups relate. Navigation is one way of exposing that structure in an interface. A sound architecture can be presented through several navigation patterns; a flawed one cannot be rescued by any of them, which is why the structure is settled first.
It can, and that has to be treated as a separate decision with its own consequences. Changing addresses affects existing links, bookmarks and search visibility, so a structural improvement that requires it needs to be weighed against that cost and planned as a migration. Where existing URLs must be preserved, the structure can usually be improved in navigation and internal linking without altering the addresses themselves.
Few enough to scan without effort and specific enough to be unambiguous, which usually lands in a modest range rather than at a fixed number. What matters more than the count is whether each label clearly excludes what belongs elsewhere. A category that could plausibly contain half the site is a problem regardless of how many siblings it has.
Only for users who already know what to call the thing they want. Search serves people with a specific target and fails people who are exploring, comparing, or unaware that a section exists. A site relying on search leaves the browsing population unserved — and heavy search usage is normally evidence the structure has failed rather than a sign it is unnecessary.
Before wireframes and long before visual design. Structure determines what screens are needed and what each has to contain, so settling it first prevents designing pages that a later restructuring makes redundant. Retrofitting architecture onto a built interface is possible and it is consistently more expensive than doing it in the right order.
Still deciding if information architecture services is right for you?
Talk to UsEveryone in the Room Understood It
Navigation structures get agreed in workshops. The categories are discussed, argued over, refined, and eventually everyone present agrees the result makes sense.
It does make sense — to a room of people who know the organisation, its divisions, its product names and its internal vocabulary. That shared knowledge is precisely what the visitor does not have.
Testing the structure with five outsiders takes an afternoon and reliably finds the categories nobody else can interpret. It is skipped because the workshop already produced agreement, and agreement feels like validation.
Free Structure Review
Find Out Whether People Can Find Things
Send us your navigation. We will assess the structure and, where it is worth it, tree test it with real participants.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists