Topic 5 — Information architecture and user flows

Goal: Organize content and map how users move through a product.

Lesson 5.1 — The invisible skeleton

Tessa's first week at Wanderwell, Priya hands her a complaint that's been piling up: people can't find where to change a trip date after they've booked. Tessa opens the app and goes looking herself. Trips? No. Account? No. It's buried under "Manage" inside a booking detail screen, three taps deep, behind a label nobody would think to tap. She's a little relieved — the screens are gorgeous, the problem isn't how anything looks.

The problem is where things live. That's information architecture (IA): organizing and labeling a product's content so people can find what they need. It's the invisible skeleton under every app — the menus, the categories, the structure. When you find a setting on the first try, good IA is the reason. When you're stabbing through five menus, that's bad IA, and you usually blame yourself instead of the design.

Tessa, eight years arranging retail floors, already has the instinct. Marcus, her mentor, names it for her with a comparison she'll keep using.

A good product is a well-run supermarket: related things in clear aisles, honest signs, and a shopper finds the milk without a map.

Bad IA is the store where pasta sits next to shampoo and the sign over aisle four lies. Nobody reads the layout diagram by the door. They just want the milk.

Lesson 5.2 — Use the words on the box

Tessa's first stab at reorganizing Wanderwell groups things the way the company thinks. She makes a top-level section called "Itineraries," because that's what everyone at the office calls a booked trip in meetings.

Marcus catches it in review. "Ask five travelers what an itinerary is," he says. "Half will guess wrong." Inside Wanderwell, "itinerary" is everyday vocabulary. To a person planning a long weekend, the thing they booked is my trip. The label was honest to the team and invisible to the user.

That's the quiet rule under all of IA: use the user's words, not internal jargon, and group things the way users expect. Three questions drive the whole exercise:

• What are the main things users need?
• How should those things be grouped?
• What do we call them, in the user's own language?

Get the grouping and the labels right and the menu feels obvious — people stop noticing it, which is the goal. Get them wrong and every screen behind the menu pays the price, no matter how polished it looks. Tessa renames the section "My trips." Support tickets about finding a booking drop the next month, and she hasn't redrawn a single pixel.

Lesson 5.3 — Don't guess the structure, test it

Here's the trap Tessa almost falls into: she's confident her new structure is right because it's obvious to her. But she's spent two weeks inside this product. The traveler hasn't. Designers don't get to be the test of their own IA.

So they use two research methods, and the difference between them matters.

Card sorting comes first, when you're trying to build the structure. You write each piece of content on a card — "cancel a booking," "view receipts," "add a traveler," "change dates" — hand the deck to real users, and ask them to group the cards and name each group. You're not testing a design. You're learning their mental model: what they think belongs together, and what they'd call the pile. Card sorting generates an IA from the inside out.

Tree testing comes after, when you have a proposed structure and want to know if it works. It's often called a reverse card sort, and the name says it. Instead of asking users to build groups, you give them your menu — just the text labels, no visuals — and a task: "Where would you go to change your trip dates?" Then you watch where they click. Tree testing evaluates an IA you already drafted.

Card sort to design the structure. Tree test to prove it. They're best friends, not rivals.

Hannah, Wanderwell's researcher, runs both for Tessa. The card sort shows that almost everyone files "change dates" and "cancel" together under a mental bucket they keep calling my trips — confirming Tessa's rename. The follow-up tree test, run on the proposed menu, shows 8 in 10 testers find "change dates" on the first try, up from almost nobody in the old app. Now Tessa isn't guessing. She has evidence, in users' own behavior, before a single high-fidelity screen exists.

Lesson 5.4 — Map the flow before you draw the screens

IA tells you where things live. A user flow tells you how a person gets through a task — the step-by-step path to a goal.

Book a trip on Wanderwell looks like this:

open app → search destination → pick a stay → choose dates → review price → enter payment → confirm → confirmation screen

Tessa draws it as plain boxes and arrows on a whiteboard, no color, no fonts. It takes ten minutes and it earns its keep immediately, because the flow shows her three things she could not see by sketching screens:

• How many steps the task takes. Fewer is usually better. Every extra step quietly loses some people — they get distracted, they bail, they lose the thread.
• Where people get stuck. A fork with no clear right answer, a dead end, a screen with no way back.
• Which screens she actually needs to build. The boxes are the screen list. No flow, and she'd design beautiful screens that don't connect.

Mapping the flow first is the move that separates "pretty screens" from a product. Dev, the engineer who'll build it, loves the whiteboard version — he can see the whole journey and flag, early, that the payment step needs a third-party service that takes a few seconds to load. Caught on the whiteboard, that's a one-line note. Caught after Tessa designs the screen, it's a redo.

This is the lesson new designers learn the hard way: the most common early mistake is designing gorgeous individual screens that don't add up to a sensible journey. The flow is what makes them add up.

Lesson 5.5 — Reduce friction

One word ties IA and flows together: friction. Friction is anything that makes a task harder than it has to be — an extra step, a confusing label, one too many choices, a form that asks for things it doesn't need. Each bit of it sheds a few users. Reducing friction is the recurring job.

Tessa goes back to her book-a-trip flow looking for friction, and she has four standard moves.

Cut steps. Her draft had a separate screen to choose dates and another to pick the number of travelers. Could those be one screen? They could. Two boxes become one, and the flow gets shorter.

Don't make me think. This is Steve Krug's first law of usability, from his classic book Don't Make Me Think. On any screen, the next action should be so obvious the user doesn't have to puzzle it out. Krug's line for the designer's job: get rid of the question marks. Every "wait, what do I tap now?" is friction.

Use familiar patterns. People already know how a shopping cart, a hamburger menu, or a back arrow works. Reinventing them to be clever just makes users relearn something they'd mastered elsewhere. Tessa wanted a novel swipe gesture for "save a trip"; Marcus talks her into the heart icon everyone already recognizes. Convention beats originality where the user's expectation is already set.

Always show where they are and how to get back. A step counter, a clear back option, a breadcrumb. People should never feel lost or trapped. The dead end is one of the cruelest forms of friction.

The payoff is counterintuitive, and it's the part Tessa learns to be proud of: the best design often makes the task feel so effortless that nobody notices the design at all. The work disappears into how easy it feels.

Worked example — Tessa fixes "change my trip dates"

Back to the complaint from week one. Tessa now runs it the full way.

She starts with IA, because the real bug was where the thing lived. Hannah runs a quick card sort: travelers consistently group "change dates," "cancel," and "view receipt" into a pile they name my trips. Tessa makes "My trips" a top-level destination and drops the office word "itinerary." She drafts the menu and Hannah runs a tree test on it — 8 in 10 testers now find "change dates" on the first try.

Then she maps the user flow:

My trips → pick the trip → "Change dates" → choose new dates → review any price difference → confirm → confirmation

Drawing it surfaces a snag: her first version had a separate screen explaining the change fee, then a screen to pick new dates. Two screens. She cuts a step — the fee difference now shows right on the date-picker as the user moves the dates, so there's nothing to read in advance and one fewer screen to tap through. She keeps the standard back arrow on every step (familiar pattern, never lost), and she labels the final button "Confirm new dates" so there's no question mark about what it does (don't make me think).

Dev builds it from the flow diagram. The task that used to be three confusing taps deep is now a clear five-step path from a label people actually look for. Tessa never opened a color picker. She fixed the journey, and the journey was the product.