Structure is a product decision, not a design flourish. Where something lives decides whether anyone uses it — a setting buried three levels down under a label nobody recognises is, in practice, a setting that does not exist.
Information architecture is the work of deciding what the product contains, how those things group, what each group is called, and how someone moves between them. Do it before screens. Rearranging boxes on a diagram costs an afternoon; rearranging shipped navigation costs a quarter and a support backlog.
You get no credit for this. Nobody writes in to say the menu was exactly where they expected — they write in when it is not. So measure the absence: fewer tickets asking where a thing lives, fewer features nobody uses until a salesperson points at them.
- What is information architecture? — article
- What Is Information Architecture? (UX Design Guide) — video
Site Maps
A site map is the whole product on one page — every screen or section, and what sits under what. Draw it before you design a single screen.
Its value is the zoom level. Gaps and duplication are obvious here and invisible everywhere else. You see that billing appears in two places, that help has nine children while onboarding has none, that there is no route to account deletion at all.
Keep it boring. Boxes, labels, lines. The moment it acquires visual design it stops being cheap to redraw, and a site map that is expensive to redraw has stopped doing its job.
Watch the depth. If something people need every week sits at the end of a long branch, the problem is the structure, not the wording — no label rescues a screen that far down. Fix it on the diagram, where fixing is free.
Navigation
Navigation is the architecture made visible: menus, tabs, breadcrumbs, search, back behaviour. If the structure underneath is muddled, no menu polish rescues it.
Two properties decide whether it works. Predictability: someone can guess where a thing lives before clicking, and be right. Recoverability: when they guess wrong, getting back costs one action, not five.
The usual failure is the navigation bar as a political settlement. Every team gets a slot, and the top level names your departments instead of the user's goals — a "Data Services" section because someone owns it. Nobody arrives wanting data services. They arrive wanting last month's invoices.
Test it with a first-click test: give someone a goal, say nothing else, watch where they click first. Before screens exist, run the same tasks against the bare hierarchy — tree testing. The first click is the verdict.
- Navigation design: Almost everything you need to know — article
- Information Architecture: 3 Key Models — video
User Flows
A user flow traces one goal from entry to completion, including every branch — what happens when the code expires, when the card is declined, when they already have an account. Boxes for screens, diamonds for decisions, arrows for what follows.
Draw it before the screens, because it exposes the paths that happy-path mockups quietly skip. Most of the pain in a shipped product lives in branches nobody drew.
Start at the real entry point, which is rarely your home page — an email link, a shared URL, a push notification. A flow that begins at the logged-in dashboard has hidden the hardest part of the experience from itself.
End where the user considers themselves done, which is often after your last screen: the parcel arrives, the invite is accepted.
Content Organization
Two decisions, always taken together: which things belong in the same pile, and what the pile is called. The failure mode is not bad writing — it is good content filed under a category name only your team uses.
Two techniques earn their place. Open card sorting: give fifteen people your content on cards, let them build their own groups and name them, and you learn the categories they already carry in their heads. Closed card sorting: hand them your proposed categories and see what lands where. Open when you are inventing a structure, closed when you are checking one.
Labels should use the words customers used in interviews, not the internal term. If your team says "entitlements" and customers say "what my plan includes", the customer wins.
Whatever people dump in "Other" is a category you have not found yet.
- Content organization at its finest — article
Task Flows
A task flow is one task down a single line: invite a teammate, upload a document, confirm a booking. A user flow maps every way a journey can fork; a task flow follows only the route where nothing goes wrong. Narrow on purpose.
Count things. Screens, fields, choices, and the number of times someone must leave your product and come back: to an inbox, an SMS, an authenticator app. Every departure is a place people drop out and never return.
Then attack the count. Can a field be inferred, defaulted, or asked later? Can two screens become one? Can a choice be made by you instead of by them?
Use a user flow to check the structure is right. Use a task flow to check the path is short. The first asks whether people can get there; the second asks what it costs them to arrive.
- Task Flow and User Flow Explained — article
- User Flow vs Task Flow in UX Design — video