Organising business software so people find what they need
Your team cannot find anything in the software they use eight hours a day. Not because the features are missing, but because the navigation was never designed. The application started with five screens and a simple sidebar. Three years later it has forty screens, a flat list of menu items with inconsistent labels, and new starters who take weeks to learn "where everything is" by memorising click paths instead of understanding the structure.
That is an information architecture problem. Information architecture (IA) is the practice of organising, labelling, and structuring content within an application so that people can find what they need and understand where they are. Rosenfeld and Morville defined the discipline around four components: organisation, labelling, navigation, and search. In business software, each of these translates into a design decision that directly affects findability, onboarding time, and task completion speed.
The four IA components in business software:
Organisation: How screens and features are grouped into sections and modules.
Labelling: What menu items, buttons, and section headers are called.
Navigation: How users move between areas of the application.
Search: How users find specific records or actions without browsing.
Poor IA has measurable costs. In a team of 10 to 50 people, navigation confusion generates internal support tickets ("where do I find X?"), stretches onboarding from days to weeks, slows task completion as staff hunt through menus, and increases data entry errors when people land on the wrong screen. Most businesses attribute these problems to training gaps when the actual cause is structural.
Information architecture decisions: navigation structure
Navigation structure is the most tangible IA decision in any business application. It determines how quickly people move between functional areas (CRM, invoicing, reporting, stock management) and whether they can build a reliable mental map of the system. The choice comes down to three patterns.
Hick's Law tells us that decision time increases with the number of choices. A flat sidebar with 30 menu items is measurably slower to use than a grouped structure with six top-level categories. But deep nesting creates its own problem: three levels of content hierarchy mean three clicks to reach anything, and users lose track of where they are.
| Pattern | Works when | Breaks when |
|---|---|---|
| Sidebar navigation | Deep hierarchies with many modules. Users spend most of their session within one area and need quick access to sub-screens. | Fewer than six top-level areas. A sidebar for five items wastes screen space. |
| Top-bar navigation | Flat structures with six or fewer top-level sections. Each section contains its own content without deep sub-navigation. | 10+ functional areas or two levels of navigation depth. Top bars do not handle depth well. |
| Hybrid (top-bar + sidebar) | Multi-module applications where the top bar handles module switching (CRM, Finance, Warehouse) and the sidebar handles within-module navigation. | Users frequently cross between modules in a single task. Two navigation layers add cognitive load. |
The hybrid approach deserves particular attention for growing business software. It uses progressive disclosure at the navigation level: the top bar shows the big picture, the sidebar shows detail for the current context. This keeps the visible item count manageable while supporting dozens of screens across modules, directly supporting reducing clicks and friction in daily workflows.
Information architecture decisions: labelling
Structure gets the attention, but labelling does the communicating. Every menu item and button label is a promise: click here and you will find this. When labels match the user's mental model, navigation feels obvious. When labels reflect the developer's database schema ("Entities," "Transactions," "Resources"), navigation feels foreign. This gap is central to how users build mental models of your software.
Information scent theory explains why. Users scan navigation like a trail, following labels that "smell" like they lead to the right place. "Stock Adjustment" has strong scent for a warehouse operative correcting inventory. "Inventory Transactions" has weaker scent for the same task, even though it leads to the same screen. The specific challenge in business software is domain vocabulary: finance calls it "invoices," warehouse calls it "purchase orders," and a labelling system has to navigate this taxonomy without forcing one department's language on another.
The practical test: put a new starter in front of the application and ask them to find a specific screen using only the menu labels. If they cannot do it within ten seconds, the naming conventions are wrong. This "new starter test" exposes labelling problems that experienced staff have stopped noticing because they memorised the paths long ago.
Restructuring information architecture in existing software
Most IA guidance assumes you are designing from scratch. The harder and more common problem is restructuring navigation in software people already use daily. The application accumulated modules over years, labels were chosen by whichever developer built each feature, and nobody revisited the overall structure. The result: a flat list of 30+ items, some duplicated, some grouped inconsistently.
Before committing to a full restructuring, identify what type of problem you have. Sometimes the structure is sound but the labels are wrong. Sometimes both need fixing.
Restructure or relabel?
Relabel first if users find the right section but struggle with individual screen names. Run the new starter test (above). If they navigate to the correct area but pick the wrong item, labelling is the problem.
Restructure if users cannot find the right area at all, if the menu has duplicate destinations, or if the grouping no longer reflects how the team actually works. Start by mapping existing workflows before restructuring to understand which screens people use together.
Nobody wants to touch it. "People know where things are." But the ongoing cost of poor information architecture (slower onboarding, higher support load, lower data quality) compounds every month. The disruption from restructuring is temporary.
The progressive rollout is critical. People resist navigation changes because they have memorised click paths. Running both structures in parallel (new as the default, old behind a toggle) gives users time to adjust while signalling that the change is permanent. Set a deprecation date and communicate it clearly. Most teams adapt within two to three weeks.
Testing whether your information architecture works
Internal debate about navigation structure can run for months. Two IA validation methods resolve those debates in under an hour.
Card sorting reveals how users naturally group concepts. Write each screen name on a card, hand the cards to five staff members, and ask them to sort into groups that make sense to them. What emerges is often radically different from how the current navigation organises things. Open card sorting (users create their own group names) works best when starting fresh. Closed card sorting (predefined groups) validates a proposed structure.
Tree testing is the complement. You present a proposed navigation tree and give staff specific tasks: "Find the screen where you would adjust stock levels." Staff navigate the tree by clicking through labels, with no visual design to guide them. If five out of five find it, the structure works. If three get lost, the grouping needs rethinking. Optimal Workshop offers dedicated tools for both methods (OptimalSort for card sorting, Treejack for tree testing), though paper cards work perfectly for a team of 20.
Both methods take less than an hour with five to eight participants and reveal problems that months of discussion cannot. Test before you build. It is cheaper to rearrange cards than to rearrange code.
Common information architecture mistakes in business software
These are the patterns we see most often in business applications that have outgrown their original navigation. Each one is fixable, but they compound when left unaddressed.
If three or more of these apply to your application, the information architecture needs attention. The restructuring process above is where to start.
Wayfinding cues and role-based navigation
Good structure still needs moment-to-moment signals telling users where they are. The minimum set of wayfinding cues: breadcrumb navigation showing the path to the current screen, a highlighted active state on the current menu item, and section headers reinforcing context. Maintaining consistent interface patterns across your application makes these cues reliable rather than decorative.
Design principle: Design your IA at the most restricted permission level first, then add items for broader roles. If the navigation makes sense for a warehouse operative who sees three sections, it will make sense for the admin who sees twelve. The reverse is not true.
Role-based navigation is a design problem, not a permissions checkbox. When you hide menu items for the warehouse role, the remaining contextual navigation must still make structural sense. Empty groups, orphaned categories, and visible gaps undermine the experience for restricted users. Permission-aware IA means designing a coherent experience at every access level.
For record-heavy applications, search becomes navigation in its own right. Faceted search (filter by type, status, date, owner) and global search supplement browsing when the volume makes clicking through lists impractical. Saved filters let frequent users bypass navigation entirely for common lookups.
Information architecture is a business performance issue
Information architecture in business software is not a UX nicety. It is a structural decision that directly affects onboarding duration, support request volume, and task completion speed. Navigation structure, labelling, and wayfinding are the three information architecture decisions that matter most in business software, and all three are fixable in existing applications.
Restructuring existing navigation is the harder problem, but phased migration makes it manageable. Testing with real staff through card sorting and tree testing resolves debates faster than internal discussion ever will. The anti-patterns above give you a quick diagnostic. The restructuring process gives you a path forward. For more on how information architecture feeds into screen-level decisions, explore how we approach dashboard design.
Fix the navigation your team works around
If your team struggles to find what they need in the software they use every day, that is an IA problem we can help with.
Book a discovery call →