Information Architecture People Can Navigate Without Thinking
Deciding how modules, menus and content are grouped, named and nested, so the tenth visit is as easy as the first. GullySystem structures navigation for new software and reorganises it for products that have outgrown their menu.
What Information Architecture Decides
Before any screen is laid out, something has to decide where each thing lives, what it's called, and how deep someone has to click to reach it. That's information architecture — the structure underneath the visual design.
- Covers the menu, the naming of modules and fields, and the nesting of screens beneath them
- Suited to a new product being structured for the first time, and to one whose menu has grown past sense
- Decided and tested before wireframes settle what appears on any individual screen
- Includes search and findability, not navigation alone
Where Navigation Breaks Down
A structure rarely fails all at once. It degrades one addition at a time until it no longer resembles a plan.
The Menu Grew by Adding, Never by Reorganising
Every new feature became a new top-level entry, and the list is now longer than most people will read past the fourth item on.
Two Names for the Same Thing
One screen calls it 'Clients', another calls it 'Accounts', both meaning the identical table. A new joiner assumes they're different and spends a week confused about which one to use.
The Daily Task Sits Three Levels Deep
The action performed fifty times a day is buried behind a menu, a submenu and a tab, because it was placed near the data it edits rather than near the person who needs it constantly.
Search Exists but Nobody Trusts It
Results miss half of what's actually there, so people click through the menu structure by habit instead of typing what they're looking for, and the search box becomes decoration.
Every Role Sees the Same Forty Menu Items
A role that genuinely needs three of them sees the full administrator menu anyway, and spends real time each day filtering out what doesn't apply.
How We Structure a Product
Structure is tested with real people, not decided by whoever happens to be in the planning meeting.
Content Inventory
Every module, report and setting currently in the product, or planned for it, listed out so the structure is built against the whole picture rather than whatever's easiest to remember.
Grouping by Task, Not by Database Table
Items are grouped by the decision or task they support, which is rarely the same grouping the underlying data happens to sit in.
One Name per Concept, Enforced
A glossary settles which word wins where two have been used for the same thing, and that word is then used consistently across every screen and menu.
Role-Based Trimming
Each role's menu shows only what that role needs, with the full structure still there underneath for whoever administers the system.
Tested, Not Assumed
We ask real users to find specific things in the proposed structure before it's built, using simple first-click tests, and adjust anything that consistently sends people the wrong way.
What a Structure Pass Produces
The output is a set of decisions your design and development team both work from.
- A menu and navigation map covering every role
- A naming glossary so the same concept is never called two different things
- A sitemap showing how deep any given screen sits beneath the top level
- Findability test results showing where the proposed structure worked and where it didn't
What Shapes an Information Architecture Project
The work scales with how much already exists and how tangled it has become, more than with the size of the eventual product.
- How many modules and roles the structure has to cover
- Whether this is a fresh structure or a reorganisation of naming and menus already in daily use
- How many languages the navigation and labelling need to work in
- Whether search behaviour is part of the scope, alongside the menu itself
- Whether the structure has to stay consistent across more than one product or portal sharing a vocabulary
Where Structure Work Connects
Structure decides what exists and where. What each individual screen actually contains is settled in the wireframing stage that follows.
Frequently asked questions
Is this the same as UX wireframing?
No, though the two follow each other closely. Information architecture decides the structure — what exists, what it's called and how it's grouped across the whole product. Wireframing then decides what appears on each individual screen inside that structure. Getting the structure right first means fewer screens need redrawing later.
Can you reorganise navigation without confusing staff who already know the current menu by muscle memory?
We plan for that directly. Where a menu position is genuinely wrong, we change it; where it's merely inconsistent but functional, we sometimes leave it and fix the naming instead. Where change is unavoidable, we suggest a staged rollout and a short in-product guide rather than releasing a new structure with no warning.
Do you decide what things are called, or do we?
We propose the structure and the naming based on how your users actually talk about the work, then bring it to you for correction — a word that sounds right to a designer sometimes means something specific and different on the ground. The glossary is signed off with you before it's applied across the product.
What drives the cost of an information architecture project?
The number of modules, roles and existing naming conflicts to reconcile. A new product being structured from a clean requirement list is quicker than untangling years of menu items added by different people at different times.
How do you actually test whether a structure works?
Mainly with first-click testing: we give real users a task and watch where they click first, without any hints. If most people click the right place, the structure works for that task. If they consistently go elsewhere, that's a naming or grouping problem we fix before it's built.
What do you need from us for an information architecture project?
A full list of what the product currently contains, or is planned to contain, access to two or three people from different roles for a short testing session each, and one person who can settle naming disagreements when the glossary throws one up.
Does this cover search behaviour, or only the menu?
Both, when search is part of your product. We look at what people actually type when they can't find something through the menu, check whether search results currently reflect that, and design the indexing and result layout as part of the same structural work.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private