Information Architecture (Flows Lens)

The full IA method — card sorting, tree testing, information scent, organization schemes, labeling, taxonomy governance — lives in Information Architecture. Read that for how to derive and validate a structure. This file covers the flows side: IA as the terrain every flow crosses. Flows are movement; IA is the ground. You cannot draw an honest user flow or navigation flow over a structure that doesn't exist yet, and a bad structure quietly taxes every flow drawn on it.

The sitemap as a flow-adjacent artifact

A sitemap is the tree of what exists — pages/sections and their parent–child relations. It is NOT a flow: it has no time, no entry points, no decisions, no exits. Keep the two artifacts separate and paired: the sitemap answers "what is where," the navigation flow answers "how do people move across it." Drawing arrows on a sitemap and calling it a user flow is the most common conflation in this section (see mistakes in user flow).

Text-tree notation (used across this library) keeps sitemaps in version control next to the flows that depend on them.

What IA contributes to flows

Content hierarchy sets flow depth. Every level in the tree is a hop in somebody's path; broad-and-shallow structures shorten flows (breadth-vs-depth evidence in the companion file).
Categories and labels are the signposts flows rely on. A user flow step like "Results → Product page" silently assumes the user recognized the category and trusted the label. Weak labels turn clean flow arrows into loops (refine → refine → abandon). Label quality is tested in the companion file (card sorts, tree tests); flows inherit the results.
Taxonomies feed navigation flows: the taxonomy's facets become the filters, the preferred terms become the menu items, and synonym rings decide whether "log in / sign in" both find the door.
Search and filters are navigation, not a separate feature. Users switch between browsing and searching mid-task; the strongest structures make each rescue the other (NN/g, "Search Is Not Enough"). Facets (independent attributes, combinable) vs. filters (single-list narrowing) per NN/g "Filters vs. Facets" — for large catalogs, faceted search IS the primary navigation flow.

Worked structure — marketing site

Home
├── Services            ← task scheme: what users hire you for
├── Portfolio           ← proof, browsable
├── Case Studies        ← proof, narrative (cross-link ↔ Portfolio)
├── Resources           ← content marketing; entry point via search
├── Pricing
└── Contact

Flow consequences: most sessions enter at Resources or a Case Study from search — so those templates need breadcrumbs, service cross-links, and a route to Pricing/Contact in ≤2 hops. Error path: a renamed case-study URL must 301-redirect; a bare 404 converts a search entry into an abandonment. Abandonment tell: Pricing sessions that bounce back to Services mean the two vocabularies don't match.

Worked structure — complex app

Dashboard               ← flow hub: status + resume-work entry
├── Projects            ← the core object; deep links land here
│   └── [Project] → Assets / Reports (scoped views)
├── Assets              ← global library (polyhierarchy: also per-project)
├── Reports
├── Settings
├── Team                ← permission flows start here (see 22)
├── Billing             ← error flows end here (card failed → Billing)
└── Support             ← the recovery path for everything else

Flow consequences: Assets living both globally and per-project is a deliberate polyhierarchy — flows must show which instance a user is in (breadcrumb/scope indicator) or "Where am I?" fails. A payment-failure error flow needs a one-hop route to Billing from the failure banner. Empty Dashboard = the onboarding flow's start state. Abandonment path: users who can't find an asset fall to search; if search doesn't index both scopes, they fall to Support — or churn.

How IA decisions constrain every other flow

Entry points (user flow) are URLs the structure either gives or withholds — no clean URL per category, no deep entry.
Screen counts (screen flow) track tree depth.
Recovery routes (breadcrumbs, hubs, search) exist only where the structure put them — error flows borrow them.
Decision labels in decision flows reuse the taxonomy's terms; two names for one thing forks the flow.
Permission scoping (permission flow) follows the hierarchy: you grant access to nodes.

Change the IA and every flow drawn on it needs re-walking — which is why the tree is tested (companion file) before the flows are inked.

Checklist

Structure derived and validated per Information Architecture — not invented during flow-drawing.
Sitemap exists as a text tree, versioned beside the flows.
Sitemap and flows kept distinct: structure vs. movement.
Every flow's step labels use the taxonomy's preferred terms.
Search + facets designed as navigation paths, not bolt-ons.
Deep-entry templates (search landings) have orientation + onward routes.
Polyhierarchy instances distinguishable on-screen.
Redirect/404 behavior defined for renamed or removed nodes.
IA changes trigger a re-walk of dependent flows.

Sources

Companion file: Information Architecture — method, evidence, and primary IA sources (Rosenfeld, Morville & Arango 2015; Pirolli & Card; Larson & Czerwinski; Bates).
Nielsen Norman Group — "Search Is Not Enough: Synergy Between Navigation and Search" (Budiu), nngroup.com/articles/search-not-enough/; "Filters vs. Facets: Definitions," nngroup.com/articles/filters-vs-facets/.
"Structure is the ground, flows are the movement" framing and the ≤2-hop conversion rule of thumb are conventions of this library.