Information Architecture

Map the structural skeleton of the application — how pages, content, and navigation connect before any visual design begins.

Information architecture (IA) defines how information is organised, labelled, and navigated. It is the structural layer between requirements and visual design. A strong IA produces a routing structure that feels obvious, navigation labels that need no explanation, and page layouts that match user mental models.

What is IA in Frontend Context

In frontend development, IA translates directly to three concrete artifacts: a site map (what pages exist), a set of user flow diagrams (how users move between those pages), and a routing specification (how the URL structure reflects both).

IA decisions have long-lived consequences. URL structures become public contracts. Navigation labels get cached in users' muscle memory. A redesign of either is far more disruptive than any visual change.

Site Mapping

A site map lists every page (or screen, in a SPA) in the application, grouped by section, with the parent-child hierarchy that determines navigation nesting and URL structure.

Site map — SaaS dashboard application

/ (root)
├── /                         Landing / Marketing
├── /pricing
├── /login
├── /signup
│
├── /app (authenticated shell)
│   ├── /app/dashboard         Overview & key metrics
│   ├── /app/projects
│   │   ├── /app/projects      Project list
│   │   └── /app/projects/[id] Single project
│   │       ├── /overview
│   │       ├── /tasks
│   │       └── /settings
│   ├── /app/team
│   │   ├── /app/team          Member list
│   │   └── /app/team/invite
│   └── /app/settings
│       ├── /app/settings/profile
│       ├── /app/settings/billing
│       └── /app/settings/security
│
└── /admin (role-gated)
    ├── /admin/users
    └── /admin/audit-log

Map every page at this stage, even pages you will not build in v1. Knowing what v2 and v3 might look like prevents you from choosing a URL structure today that blocks you tomorrow.

User Flow Mapping

User flows describe the step-by-step path a user takes to complete a specific goal. Map the happy path and every meaningful variant (error states, edge cases, permission differences).

User flow — Project creation (text diagram)

[Dashboard]
  → Click "New Project"
    → [New Project Modal]
      → Enter name + select template
        → Click "Create"
          → [API call]
            → Success → Redirect to /app/projects/[new-id]/overview
            → Name conflict → Inline error on field, stay in modal
            → API error → Toast notification, modal stays open
          → Click "Cancel" → Modal closes, dashboard unchanged
    → Name field empty
      → Submit blocked, inline validation message shown

Document flows for every primary user task identified in requirements. A minimum viable flow map covers: onboarding, core task completion, error recovery, and account management.

Choose navigation patterns based on the depth and frequency of the content, not on visual preference. The wrong pattern imposes cognitive load at every interaction.

Pattern	Use when	Avoid when
Top navigation bar	5–8 top-level sections, all equally important	More than 8 items, or deep content hierarchies
Side navigation	Applications with 3+ levels of depth, frequent switching between sections	Simple sites with few pages
Breadcrumbs	Deep hierarchies (3+ levels), users navigate back frequently	Flat structures — breadcrumbs add noise
Tabs	2–6 views of the same content entity (e.g. project tabs)	Cross-entity navigation — tabs are not pages
Nested sidebar	Admin or settings UIs with many categorised options	Marketing sites — too heavy
Command palette (cmd+K)	Power users with many possible actions	Not a replacement for primary nav

Routing Strategy

URL design is API design. URLs are shared, bookmarked, and appear in error logs. Make them meaningful, predictable, and stable.

URL conventions

Use lowercase kebab-case for all URL segments: /team-settings, not /teamSettings
Use plural nouns for collections: /projects, /users
Use IDs for resource identifiers: /projects/[id]
Use nested routes to represent ownership: /projects/[id]/tasks/[taskId]
Use search params for filters and state that should be shareable: ?status=active&sort=updated
Never encode session or auth state in the URL

Next.js App Router structure

Next.js App Router — route mapping

app/
  page.tsx                          → /
  login/page.tsx                    → /login
  app/
    layout.tsx                      → Auth shell (shared across /app/*)
    dashboard/page.tsx              → /app/dashboard
    projects/
      page.tsx                      → /app/projects
      [id]/
        layout.tsx                  → Project shell with tabs
        overview/page.tsx           → /app/projects/[id]/overview
        tasks/page.tsx              → /app/projects/[id]/tasks
        settings/page.tsx           → /app/projects/[id]/settings
  (auth)/                           → Route group, no URL segment
    login/page.tsx
    signup/page.tsx

Content Hierarchy

Within each page, define the visual and semantic hierarchy of content before design begins. This answers: what is the most important thing on this page, what is secondary, and what is tertiary?

Use a simple priority ranking per page. This directly informs the heading structure (which matters for both accessibility and SEO) and the visual weight distribution in the layout.

Content hierarchy — project overview page

H1:  Project name (primary identifier)

P1 (Primary):
  - Project status + progress metric
  - Overdue tasks count (action-required signal)

P2 (Secondary):
  - Recent activity feed
  - Team members assigned
  - Due date

P3 (Tertiary):
  - Project description
  - Tags / metadata
  - Created by / created at

Actions (always visible):
  - Primary: "Add Task"
  - Secondary: "Invite Member", "Edit Project"
  - Destructive (hidden behind menu): "Archive", "Delete"

If you cannot rank the content on a page, the page is doing too many things. Split it. Pages with a single clear primary action consistently outperform pages that try to surface everything at once.