Information architecture: why some apps feel obvious

Two school portals do exactly the same things: fees, results, the timetable, messages from teachers.

In the first, a parent opens it and immediately sees Pay school fees, Check results and Messages. In the second, fees are under Bursary, results are inside Academics → Assessment → Terminal reports, and messages live in a menu called Communication centre. Same features, same data. One feels obvious. The other needs someone to show you around.

The difference isn't the colours or the buttons. It's the information architecture: how the content is organised, grouped and named before anyone draws a screen. This module teaches you to do that well.

Words in this lesson

IA is the skeleton; navigation is what shows

Nielsen Norman Group describe information architecture as having two main parts:

1. Identifying and defining the content and functionality: what's actually in the product.
2. The underlying organisation, structure and naming that define how all that content relates.

And they make a point beginners often miss:

The information architecture (IA) is not part of the on-screen user interface (UI) — rather, IA informs UI.

Navigation is different. NN/g describe it as a collection of interface components whose main goal is to help people find information and functionality, and encourage them to take the actions you want. They quote a helpful picture: navigation is the tip of the iceberg sitting on top of the information architecture.

        ▲  Navigation: tabs, menus, links     ← what people see
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      ███  How content is grouped             ← information
     █████ How it's structured                   architecture
    ███████ What things are called

Why skipping IA is dangerous

NN/g warn that ignoring IA and focusing only on navigation is inefficient and even dangerous. One trap they describe: choosing a navigation pattern because it looks good, and then forcing the content to fit it, compromising a structure that would have served people better.

It's the same mistake as the church's app in Module 1, at a smaller scale: picking the solution, a nice-looking menu, before understanding the problem, which is how people think about the content.

Organise by how people think, not how the business is run

Most bad IA copies the organisation chart. The school has a Bursary department, so the portal has a Bursary section. The bank has a Retail Operations team, so the app says Retail Operations.

But parents don't think "I need the Bursary". They think "I need to pay fees". That expectation is their mental model, and good IA matches it.

This is exactly what your research in Module 2 was for. The words people used in interviews, and the way they described their tasks, tell you how they expect things to be organised.

Ways to organise content

There's more than one sensible way to group things. The right one depends on what people are trying to do.

Most real products mix these. A school app might organise its main navigation by task, and then organise results by time.

Shallow or deep?

Structure is also about depth: how many levels someone must go through to reach something.

• Too deep: Home → Academics → Assessment → Terminal reports → 2025/26 → First term. Every extra level is another decision, and another chance to go the wrong way.
• Too flat: forty items on one screen, with nothing grouped. Easy to reach, hard to scan.

There's no magic number. The aim is that people can predict where things are, and that the things they need most often take the fewest steps.

Step 1: take a content inventory

You can't organise what you haven't listed. A content inventory lists everything the product contains or lets people do.

For a small clinic app, the start of an inventory might look like this:

Listing who needs it and how often matters. The things many people need often, like booking and opening hours, deserve the most prominent places. The emergency number is rarely needed, but when it is, it must be instantly findable. That's a structure decision, not a colour one.

Step 2: group it, then check with real people

Once you have a list, you group it. The trap is grouping it the way you think. The next lesson teaches card sorting, a method for letting real people show you how they would group it, and tree testing, for checking whether they can find things in the structure you choose.

Step 3: draw the sitemap

A sitemap shows the structure at a glance:

Clinic app
 ├─ Appointments
 │   ├─ Book an appointment
 │   └─ My appointments (change or cancel)
 ├─ My health
 │   ├─ Test results
 │   └─ Prescriptions and refills
 ├─ Pay a bill
 └─ About the clinic
     ├─ Opening hours and location
     ├─ Our doctors
     └─ Emergency contact

Only after the sitemap makes sense do you choose the navigation that shows it, which is lesson 4.3.

Common mistakes

The short version

• Information architecture is how content is identified, organised, structured and named. Navigation is the on-screen part that shows it: the tip of the iceberg.
• NN/g: IA isn't part of the on-screen UI; it informs the UI. Skipping it is inefficient and even dangerous.
• Organise by people's mental models, not the organisation chart.
• You can organise by task, topic, audience, time or A–Z, and most products mix them.
• Start with a content inventory, including who needs each item and how often, then group it and draw a sitemap.

Try it yourself

1. Pick a real service you researched in Module 2, or a school, clinic, church or market app you know.
2. Build a content inventory of at least 25 items, with columns for who needs it and how often.
3. Look at an existing app or website for that service. Find three labels or sections that follow the organisation chart rather than how users think, and rewrite each in users' words.
4. Group your inventory into four to seven sections, and write down which way of organising you used: task, topic, audience, time or a mix.
5. Draw a sitemap on paper, and mark the three things people need most often. Count how many steps each one is from the start.
6. Save everything in your design-journal. You'll test it with real people in the next lesson.

You'll know you've got it when your most frequent tasks are the easiest to reach in your sitemap, and none of your section names would only make sense to someone who works there.