The Reason Some Products Feel Easy
Some products feel easy to use. You open them and you know where things are. You can find what you need without thinking. New features make sense in their place. Other products, with the same features, feel like a maze. You hunt for what you need. Things feel scattered. Adding a feature makes it worse, not better. The difference is rarely about visual design. It is about information architecture.
Information architecture (IA) is the structure of the product. How it is organised. What goes where. What is called what. How concepts relate to each other. It is the skeleton beneath the visual design. Good IA is invisible: users feel that the product makes sense without thinking about why. Bad IA is invisible too, but it produces constant friction users feel without being able to articulate.
Most PMs underestimate IA. It feels less concrete than features and less exciting than visual design. But it is structural; it shapes whether the product works at all. A feature with bad IA is harder to find than a feature that doesn't exist. This article is about what IA is, why it matters, and how PMs should think about it.
What Information Architecture Includes
IA covers a few related but distinct things. PMs benefit from understanding each.
Organisation: How Things Are Grouped
What goes together with what. Are billing settings under Account or under Settings ? Are user profiles their own section or part of People ? The grouping decisions create the mental model users build of the product. Bad grouping forces users to remember arbitrary placements; good grouping makes placement feel obvious.
Labelling: What Things Are Called
The words you use shape understanding. Is it Settings or Preferences or Configuration ? Is it Workspaces or Teams or Organisations ? Labels carry meaning. Bad labels force users to translate between the product's vocabulary and their own; good labels match what users would naturally call something.
Navigation: How Users Move Around
How users get from one place to another. Top navigation, side navigation, breadcrumbs, search, links. The navigation system tells users where they are, where they can go, and how to get back. Bad navigation produces users who feel lost; good navigation produces users who feel oriented.
Search: How Users Find Specific Things
When organisation and navigation aren't enough, search fills the gap. Good search forgives typos, surfaces relevant results, and works on the user's vocabulary. Bad search returns nothing useful or, worse, returns too many irrelevant results.
Why Most Products Have Bad IA
Bad IA is the default for most products, especially as they grow. The reasons are predictable and worth understanding.
IA Decays Over Time
When a product launches, its IA is usually clean. There are few features. The grouping is obvious. Then the product grows. Each new feature is added to the most convenient place. Over years, the IA becomes a record of the order in which things were built, not of how they should be organised. The team is too busy adding features to step back and reorganise.
Internal Models Differ From User Models
Engineering organises code by technical structure. PMs organise by feature owner. Designers organise by visual patterns. None of these match the user's mental model. Without effort to align around the user's view, the product's IA reflects internal politics, not user needs.
Naming Is Hard
Coming up with good labels is one of the hardest writing tasks. Most teams default to internal jargon ( Workspace because that's what the architecture calls it) or generic terms ( Settings for everything that isn't obviously elsewhere). Both produce labels that don't match user thinking.
The Cost of IA Changes Is High
Reorganising a product disrupts existing users. They have muscle memory. They have integrations. They have written training materials. So teams avoid IA changes even when they are needed. The IA stays bad because fixing it is scary.
Principles of Good IA
Good IA shares a few characteristics. The principles are simple to state and hard to apply consistently.
Group by User Mental Model
Things should be grouped the way users think about them, not the way the team built them. If users think of billing and account settings as one thing, they should be in one place even if engineering built them as separate systems. The user's mental model is the right input for IA decisions.
Use Words Users Use
Labels should match what users naturally call things. Research helps: ask users to describe what they're trying to do, then use their words. Add a teammate is better than Provision a new user , even if engineering thinks of it as provisioning. The user's vocabulary should win.
Be Consistent
If Settings means one thing in one place, it should mean the same thing elsewhere. If users find features by right-clicking in one part of the product, they should be able to right-click in another part. Inconsistency forces users to learn each part separately, which is exhausting.
Follow Conventions Where They Exist
Web and app conventions exist for a reason. Logo in the top left links home. Search is in the top bar. Account is in the top right. Following these conventions reduces the load on users. Breaking them requires very good reason; users will struggle to find what they need.
Make Hierarchies Shallow
Deep nested menus are hard to navigate. Three clicks to find a setting is one click too many. Flatter is usually better, even if it means showing more options at the top level. The exception is when the options are genuinely rare; then nesting is fine.
Show Where Users Are
Users should always know where they are in the product. Breadcrumbs, highlighted nav items, page titles. Without these orienting cues, users get lost in deeper sections and can't find their way back.
Two Useful Methods: Card Sorting and Tree Testing
Two research methods are particularly useful for IA work. Both are cheap to run and reveal user mental models that are hard to access otherwise.
Card Sorting
Write each major feature or page name on a card. Hand the stack to a user. Ask them to group the cards in whatever way feels natural. Watch how they group. Note where they hesitate, what they call each group, what they want to split or merge. After running this with five to ten users, patterns emerge. The patterns reveal the natural mental model for your product's content.
Two variants. Open card sorting lets users name the groups; useful when you don't yet know how things should be grouped. Closed card sorting gives users a fixed set of groups and asks them to place cards into them; useful when you have a hypothesis you want to test.
Tree Testing
Show a user the navigation hierarchy as a text tree (no visual design, just labels and structure). Give them a task: where would you go to find your billing history? Watch which branch they pick. Track success rate, time, and first clicks. Tree testing isolates the structure and labelling from visual design, revealing whether the IA alone is working.
When to Use Each
Use card sorting before you have built the IA, to discover natural groupings. Use tree testing after you have a candidate IA, to validate it. Together they form a useful research cycle: discover groupings, build a tree, test it, refine.
Common IA Patterns
Some IA patterns recur across many products. Knowing them helps you choose the right one for your situation.
Hierarchy (Tree)
The most common pattern. Top-level categories contain subcategories, which contain items. Most websites and apps use this. Works well when content has clear parent-child relationships.
Faceted
Items are tagged with multiple attributes; users filter by any combination. E-commerce uses this heavily. Works well when items have multiple meaningful dimensions and users want to slice by different ones.
Tag-Based
Items are organised by tags rather than fixed categories. Same item can appear under multiple tags. Common in knowledge bases and content systems. Flexible but can feel amorphous if not done well.
Time-Based
Items organised chronologically. Common in social feeds, activity logs, and analytics. Works when recency is the primary dimension users care about.
Spatial
Items organised by physical or simulated space. Common in design tools (canvas), maps, and games. Works when location is the natural way to think about items.
Most products use a mix. Top-level navigation might be hierarchical, search might be faceted, the activity feed is time-based. The mix is fine; what matters is that each use of a pattern is consistent and that the patterns work together.
How PMs Should Engage With IA
Notice It Early
Most PMs notice IA only when something is broken. By then, it is expensive to fix. Build the habit of noticing IA during regular product work. When adding a feature, ask: where does this go? Is the existing structure right for this addition, or does this addition reveal a structural problem?
Frame It as a Problem, Not a Solution
Move billing to its own section is a solution. Users can't find billing because it's buried under settings is a problem. Frame IA work as user problems and let designers propose structural solutions. They will often see options the PM didn't consider.
Use Research, Not Opinion
IA debates can become opinion wars. Card sorting and tree testing produce data that cuts through opinion. Eight of ten users put X under Y; that's where it should go is more persuasive than any internal argument.
Plan IA Changes Carefully
When IA changes are needed, plan for the migration. Users have muscle memory; sudden changes disorient them. Where possible, provide redirects, communicate changes in advance, and offer search as a fallback for users who can't find moved items. Major IA changes deserve their own release plan, not just a quiet ship.
Resist Adding Top-Level Sections
When a new feature comes in, the easiest answer is to add a new top-level nav item. This dilutes the existing nav and produces sprawl over time. Resist. Find the right existing section, even if it requires reorganising. Top-level real estate is precious; spend it carefully.
Common Mistakes
Mistake One: Mirroring Internal Structure
Reflecting the company's org chart in the product. The Marketing tab is everything the marketing team owns. The Sales tab is everything the sales team owns. Users don't care about your org chart. They care about their own work.
Mistake Two: Naming for the Internal Audience
Using internal terms ( SKU configuration, asset bundles, entity definitions ) in the user-facing product. Users don't know what these are. Translate to user vocabulary even when it feels imprecise to insiders.
Mistake Three: Catch-All Other Categories
Other or Miscellaneous as a section. Users have no idea what is in it. They have to open it to find out. Avoid catch-all categories; if items don't fit anywhere, the categories themselves are wrong.
Mistake Four: One-of-Each Patterns
Some products use a different navigation pattern in each section. The home is a feed; the settings are a tree; the search is faceted. Users must learn each pattern separately. Choose a primary pattern and stick to it; vary only when there is strong reason.
Mistake Five: Adding Without Reorganising
New features get added to the existing structure without considering whether the structure still works. Over years, the product accumulates features in the wrong places. The IA needs periodic refresh, not just additions. Once a year is the minimum; major redesigns may require more.
Mistake Six: Treating Search as the Solution
Some teams figure that if IA is hard, they'll just rely on search. Users will search if they can't find it. But search is a fallback, not a primary IA. Most users browse before they search. If they can't browse to what they need, they assume it doesn't exist. Good IA reduces the load on search; great IA makes search rare.
When to Invest in IA
IA is investment, like any other product work. The right moments to invest are not random.
Before a Major Feature Launch
If you are about to add a significant new area to the product, audit the existing IA first. The new feature's placement is part of its design. Adding it to a broken IA compounds the problem; fixing the IA first lets the new feature land cleanly.
When Users Repeatedly Can't Find Things
Patterns in support tickets, sales calls, or onboarding feedback that mention where is X are signs of IA problems. When several signals converge, the IA needs attention. Don't wait until it becomes a crisis.
During Major Strategic Shifts
If the product is repositioning (e.g., moving from individual to team use, or from small business to enterprise), the IA may need to change to match the new user mental model. The same content organised differently tells a different story.
When Adding a Tab Becomes the Default Answer
If every new feature ends up as a new top-level nav item, the IA is breaking. The fix is to reorganise so the structure can absorb new features without sprawl. Without this discipline, every product eventually has a bloated navigation that nobody can scan.
A Final Word
Information architecture is structural work. It is less visible than visual design but more determinative of whether the product works. Users feel good IA without noticing it; they feel bad IA as constant friction they can't articulate. The PMs and designers who pay attention to IA build products that scale, while teams that ignore it produce products that get worse over time.
If you take one practice from this article, take this: every quarter, run a five-user card sort or tree test on your product. Ask users to find five things they would actually need to find. Track success rate. The number tells you whether your IA is working. The qualitative patterns tell you what to fix. Over a year, you will develop both an instinct for IA and a record of how it evolves with your product.
Key Takeaways
- Information architecture is the structure underneath the visual design: how things are organised, labelled, navigated, and searched. Bad IA is invisible friction.
- IA decays over time as features are added in convenient rather than principled places. Periodic IA refresh is healthy.
- Group by user mental model, label with user vocabulary, be consistent, follow conventions, keep hierarchies shallow, and orient users.
- Card sorting reveals natural groupings; tree testing validates a candidate IA. Both are cheap and reveal user thinking that internal debate cannot.
- Resist adding top-level nav items as the default answer to new features. Plan IA changes with care; sudden reorganisation disorients existing users.