By the end of the lesson, you understand that information architecture is not a list of menu items, but a system of content, labels, and decision paths adapted to user tasks. You can tell organizational naming apart from the user's language, check the comprehensibility of a category or label with simple methods (card sorting), and make a sitemap.
Why does information need to be organized?
Imagine a library where the books are in the order of their arrival. Everything is there, yet you cannot find anything. It is the same on a digital interface: the existence of information is not enough, findability counts. Information architecture decides what is where, what calls what, and what is connected to what. This affects navigation, search, the flow, and the later layout of the wireframe.
How does the user look for information?
Information architecture (IA) is the task-oriented organization of content, categories, labels, and navigation. Not all content is equally important. IA decides what is on the first level, what to show only when needed, and which details help the decision. A structure that is too flat gives many equal choices; a structure that is too deep hides the path to the goal. The right depth depends on how often, how confidently, and with what consequence the information is sought.
We touched on the concept of the mental model (the user's idea of how the system works) in chapter 3. Here the question is how we find out what the user's mental model of our content is.
Content inventory and prioritization
The first step of IA is the content inventory: list what information and functions are needed for the main task, and which of them is primary and which is secondary. On an event page the date, location, price, and registration requirement are often the primary decision data. The organizer's whole story or archived news can be secondary. The layout is not a value judgment about the content; it serves the current task.
You can record it with a simple table:
Content
Importance for the main task
Where does it appear?
Event name, date, start time
Primary
Card
Price, language, registration requirement
Primary
Card
Organizer introduction
Secondary
Detail page
Past events
Tertiary
Organizer page
Labels as promises
A label promises what content or action follows after the click. "More" and "Information" make little promise by themselves. "Change booking", "Admission requirements", or "Today's events" are more concrete. A good label:
is short,
speaks the language of the target audience,
cannot be confused with another concept in the context,
says what is behind it (not "Services", but "Today's events").
Card sorting
Card sorting is a research method in which users group content elements. With its help you find out how users would group, and what words they use for the groups.
Steps:
Write the content elements on cards (15–30 elements).
The participant groups them as is logical for them.
Have them name the groups.
Collect from several participants, and look for recurring patterns.
Two variants:
Open card sort: the participant creates the groups and names themselves. Good for researching a new structure.
Closed card sort: they sort into predefined categories. Good for checking an existing structure.
Even with a small sample this can reveal unexpected names or categories. We are not seeking a final truth, but a signal of where the designer's logic differs from the user's. A supplementary method is the tree test: the participant gets a task ("Where would you look to cancel a registration?") and has to click in a text-only menu tree, without graphic elements. This way you test the structure purely.
Sitemap
A sitemap is a hierarchical map of the product's pages (screens): it shows what is under what, and how things are connected. It does not show the user's path (that is the user flow), but the structure.
flowchart TD
A["Home:<br>Today's events"] --> B["Event details"]
A --> C["Filters"]
A --> D["Saved events"]
B --> E["Registration"]
E --> F["Confirmation"]
D --> B
A --> G["Account"]
G --> H["My registrations"]
H --> B
Tips for the sitemap:
The path to the main task should be shortened: it should be reachable from the home page in as few steps as possible.
Mark which pages are entry points (home, search), and which are reachable only through a link.
Do not draw every window and every state: the sitemap thinks at the page level.
A single branch should not have too many direct children (generally 5–9 is already a lot).
Worked example: the IA of Mai program
The Mai program team originally plans the menu items "Events", "Categories", "Organizers", and "About us". With card sorting, however, it turns out that students group events by time and cost ("Tonight", "Free", "Weekend"), and the concept "Categories" means nothing to them. The fix is not just renaming: the first level leads to the task: "Tonight", "Free", "Saved". The internal categories (music, film, sport) stay in the background as filters, but they do not direct the first step.
Common misconceptions
Claim
Clarification
"The exact official name is always the best label."
If the target audience does not know it, a plain-language name and a supplementary explanation may be needed.
"More categories are more detailed, therefore better."
The cost of choosing can grow if the differences are not understandable.
"A good label works the same everywhere."
Meaning is also influenced by the context and the user goal.
"The sitemap is the user's path."
The sitemap is the structure; the route is shown by the user flow.
In brief
IA is the task-oriented organization of content, labels, and routes, not a menu list.
The content inventory shows what is primary for the main task.
A label is a promise: concrete, in the user's language.
Card sorting and the tree test reveal, even with a small sample, the gap between organizational and user logic.
The sitemap shows the structure of the product, not the route.
Review questions
Which label might a new user of your project misunderstand?
Which internal organizational category does not match the user's question?
Which decision data should you bring forward?
How would you check the comprehensibility of your labels on a small sample?
Content, labeling, and the sitemap
Objectives
By the end of the lesson, you understand that information architecture is not a list of menu items, but a system of content, labels, and decision paths adapted to user tasks. You can tell organizational naming apart from the user's language, check the comprehensibility of a category or label with simple methods (card sorting), and make a sitemap.
Why does information need to be organized?
Imagine a library where the books are in the order of their arrival. Everything is there, yet you cannot find anything. It is the same on a digital interface: the existence of information is not enough, findability counts. Information architecture decides what is where, what calls what, and what is connected to what. This affects navigation, search, the flow, and the later layout of the wireframe.
How does the user look for information?
Information architecture (IA) is the task-oriented organization of content, categories, labels, and navigation. Not all content is equally important. IA decides what is on the first level, what to show only when needed, and which details help the decision. A structure that is too flat gives many equal choices; a structure that is too deep hides the path to the goal. The right depth depends on how often, how confidently, and with what consequence the information is sought.
We touched on the concept of the mental model (the user's idea of how the system works) in chapter 3. Here the question is how we find out what the user's mental model of our content is.
Content inventory and prioritization
The first step of IA is the content inventory: list what information and functions are needed for the main task, and which of them is primary and which is secondary. On an event page the date, location, price, and registration requirement are often the primary decision data. The organizer's whole story or archived news can be secondary. The layout is not a value judgment about the content; it serves the current task.
You can record it with a simple table:
Labels as promises
A label promises what content or action follows after the click. "More" and "Information" make little promise by themselves. "Change booking", "Admission requirements", or "Today's events" are more concrete. A good label:
Card sorting
Card sorting is a research method in which users group content elements. With its help you find out how users would group, and what words they use for the groups.
Steps:
Two variants:
Even with a small sample this can reveal unexpected names or categories. We are not seeking a final truth, but a signal of where the designer's logic differs from the user's. A supplementary method is the tree test: the participant gets a task ("Where would you look to cancel a registration?") and has to click in a text-only menu tree, without graphic elements. This way you test the structure purely.
Sitemap
A sitemap is a hierarchical map of the product's pages (screens): it shows what is under what, and how things are connected. It does not show the user's path (that is the user flow), but the structure.
flowchart TD A["Home:<br>Today's events"] --> B["Event details"] A --> C["Filters"] A --> D["Saved events"] B --> E["Registration"] E --> F["Confirmation"] D --> B A --> G["Account"] G --> H["My registrations"] H --> BTips for the sitemap:
Worked example: the IA of Mai program
The Mai program team originally plans the menu items "Events", "Categories", "Organizers", and "About us". With card sorting, however, it turns out that students group events by time and cost ("Tonight", "Free", "Weekend"), and the concept "Categories" means nothing to them. The fix is not just renaming: the first level leads to the task: "Tonight", "Free", "Saved". The internal categories (music, film, sport) stay in the background as filters, but they do not direct the first step.
Common misconceptions
In brief
Review questions