Information architecture: why some apps feel intuitive and yours doesn't

Your product has 40 screens and users can’t find the one they need. They click Settings looking for Billing. They search for a feature that’s buried three levels deep in a menu labeled “Tools.” They message support asking how to do something that’s on the screen — they just didn’t see it.

This isn’t a design problem. Your buttons are styled. Your colors are consistent. The issue is underneath the design: your information architecture is broken. Things are organized the way your developer thought about them, not the way your users think about them.

A developer puts “Invoice Settings” under Settings > Billing > Configuration. A user looks for it under “Invoices.” Same feature, two completely different mental models. When the product follows the developer’s model instead of the user’s, every screen feels like a puzzle.

What information architecture actually means

IA answers three questions:

1. Where does everything live? Every screen, every feature, every piece of content has a “home.” If two features live in the same place but do unrelated things, users get confused. If one feature could logically live in two places, you need to pick one and add a shortcut from the other.

2. What is everything called? Labels matter more than you think. “Analytics” vs “Reports” vs “Insights” vs “Dashboard” — these all mean different things to different people. Pick the word your users use, not the word your team uses. A card sort with 5 users takes 30 minutes and tells you which labels work.

3. How does everything connect? If a user is looking at an invoice, can they get to the client’s profile in one click? If they’re on a project page, can they see related tasks without navigating away? Good IA creates shortcuts between related things. Bad IA forces users to go Home → Clients → Search → Client → Projects → Project → Tasks for something they do 10 times a day.

The 3 rules of product navigation

Rule 1: Maximum 7 top-level items. Miller’s law — humans hold 7 (plus or minus 2) items in working memory. If your main navigation has 12 items, users scan without reading. Five to seven items is the sweet spot. Everything else goes into logical sub-sections.

Rule 2: 2 clicks to any feature. If a common action takes more than 2 clicks from the main screen, the structure is too deep. Flatten it. Move frequent actions closer to the surface. Rare actions can live deeper — nobody minds clicking 3 times to change their timezone.

Rule 3: Labels match user language. Run a quick test: ask 5 potential users “where would you go to [do X]?” If they all say “Settings,” don’t call it “Preferences.” If they say “My stuff,” don’t call it “Asset Management.” The UX design principles start with clarity — and clarity starts with vocabulary.

How to build IA for your product

The card sort method (30 minutes)

Write every feature and page name on a card (physical or digital). Give the cards to 5 users. Ask them to group them into categories and name each category.

You’ll notice: users rarely create the same groups as your development team. Developers group by technical module (Users, Billing, Content, Settings). Users group by task (Getting Started, Managing My Work, Checking Results, Getting Help).

The user groupings become your navigation. Not your developer’s mental model. Not your organizational chart. The way your users think about their work.

The sitemap

After the card sort, draw a sitemap. It looks like an org chart:

• Home
  • Dashboard — overview metrics
  • Projects — active projects, create new project, project detail (tasks, files, team)
  • Clients — all clients, client detail (projects, invoices, notes)
  • Invoices — unpaid, all invoices, create invoice
  • Settings — profile, billing, team management

5 top-level sections. Each 1-2 levels deep. Every common task reachable in 2 clicks. This sitemap becomes the blueprint for your wireframes and the navigation your developer builds.

Test the structure before building

Create a simple clickable prototype with just navigation — no content, just menus and page titles. Give 5 users tasks: “Find the invoice for Client X.” “Create a new project.” “Change your email address.”

Track completion rate and time. If users complete tasks in under 10 seconds, the IA works. If they take 30+ seconds or go to the wrong section first, the labels or groupings need adjustment.

This test costs $0 (use Figma’s free tier) and takes 2 hours. It prevents the most frustrating type of product failure: software that has the feature but users can’t find it.

When IA breaks and what it costs

Bad information architecture shows up in three metrics:

High support ticket volume. If your top 5 support tickets are “how do I find X?” — the feature exists, users just can’t locate it. Every support ticket costs $15-$25 in team time. Fix the IA and you cut 30-50% of support volume.

Low feature adoption. You built a reporting feature. 8% of users use it. Not because it’s bad — because it’s buried under Settings > Advanced > Reports instead of being a top-level nav item.

High bounce on key pages. Users land on the dashboard, see 15 widgets, and leave. They landed because they wanted to do one thing. The design system might be consistent, but if the page structure overwhelms instead of guides, consistency doesn’t help.

---

If users are getting lost in your product, the structure needs work — not the styling. We’ll map your IA, run card sorts, and deliver a navigation system that puts every feature where users expect it. Let’s fix it.