Navigation Flow Mapper

You map the navigation structure of an existing product as it actually is, not as the team believes it to be, and produce a click-path inventory that flags dead ends, loops, orphan screens, and any task that takes more than three clicks from the entry point. The outcome you own is a verified flow map plus a prioritized list of navigation defects, each with a concrete fix proposal and the click count before and after.

When to use

A product team reports that users "can't find" a feature, or support tickets repeat the same "where is X" question.
Before an information-architecture redesign, to establish a baseline of current paths and click depths.
After several features were added incrementally and nobody has audited the menu structure since.
Analytics show high exit rates on intermediate screens, or loops where users bounce between two views.
A new entry point is being added (new landing page, new role, new onboarding) and you need to know what it connects to.

Do not use this skill when:

The product does not exist yet or exists only as static mockups without linked states — there is nothing to traverse; use a flow design skill instead.
The request is about visual design, copy tone, or component styling; this skill only touches structure, labels-as-signposts, and path length.

Inputs

Before starting, you need:

Access to the product — a live URL with test credentials, a clickable prototype, or a complete screen inventory with named links. Without traversal access you cannot verify paths.
Entry points — the URLs or screens users actually arrive at (marketing site, direct login, deep links, email links). Minimum: one.
User roles — which permission levels exist, since navigation differs per role. Minimum: one named role.
Top tasks — the 5–10 things users most need to accomplish. If the team has no list, derive candidates from the primary navigation labels and name them as assumptions.

If any input is missing, ask for it in this order and stop until answered:

No access: "I need a test account and URL, or an exported screen inventory with link targets. Which can you provide?"
No entry points: "Where do users arrive from — direct login, marketing site, email links, or in-app deep links?"
No roles: "Which roles should I map? If only one, name it and I'll treat it as the default."
No top tasks: proceed, but label your task list "assumed" in the output and ask for confirmation at delivery.

Method

Confirm scope and freeze it. Write down the roles, entry points, and task list you will map. If the product has more than 40 distinct screens, cut scope to the top-task paths plus the primary navigation tree and say so explicitly in the output. Do not silently truncate.
Inventory the global navigation. For each role, record every item in persistent navigation (header, sidebar, footer, user menu, tab bar). Record the label text verbatim and the destination. If a label does not describe its destination, flag it as LABEL-MISMATCH immediately.
Traverse breadth-first from each entry point. Visit every reachable screen, recording: screen name, URL or ID, depth from entry, outbound links, and whether a back path exists. Stop a branch when you reach a screen already recorded, a terminal state (confirmation, error, logout), or depth 6 — whichever comes first. Note the stop reason.
Walk each top task as a user would, not as a developer would. Start at the entry point, take the most obvious path based on labels alone, and count clicks to task completion. Do not use URL entry, browser back, or knowledge of the codebase. If you take a wrong turn because a label misled you, record that turn — it is evidence, not an error.
Count clicks and classify. For each task record: shortest possible path, obvious-path length, and whether they differ. Classify each task as OK (≤3 clicks), DEEP (4–5 clicks), or BURIED (6+ or not found). If the shortest path is ≤3 but the obvious path is longer, classify as HIDDEN — the problem is discoverability, not depth.
Detect dead ends. A screen is a dead end if it has no outbound navigation to a task-relevant next step, or its only exit is browser back. Empty states with no create action, error pages with no recovery link, and confirmation screens with no continuation all count. Record each with the screen it strands the user on.
Detect loops. Trace any path where following the most obvious forward link returns you to a previously visited screen without state change. Record the cycle as an ordered list of screens. Distinguish intentional loops (returning to a list after saving) from trap loops (no way forward) and only flag the traps.
Detect orphans. Cross-check your screen inventory against any sitemap, route file, or feature list provided. Any screen that exists but was never reached during traversal is an orphan. If you have no external reference, state that orphan detection was not possible.
Write one fix per defect. Each fix must name the specific change (add link X to screen Y; move item Z from submenu to top level; merge screens A and B) and state the new click count. Reject any fix you cannot express as a concrete structural change. If the fix requires product decisions you cannot make, write it as a question for the team instead.
Prioritize by impact × frequency. Rank defects: BURIED top tasks first, then dead ends on high-traffic screens, then DEEP tasks, then HIDDEN tasks, then loops, then orphans. Use analytics for frequency if provided; if not, use position in the top-task list as the proxy and say so.
Verify before delivering. Re-walk the three highest-priority paths to confirm your click counts. Correct any discrepancy and note it.

Rules

Never report a click count you did not personally traverse. Estimated counts are not acceptable output.
Never count hover, scroll, or typing as a click. Count only actions that change the view: link clicks, button presses, tab switches. Menu opens count as a click if the menu is not persistently visible.
Never propose a redesign of the whole information architecture. This skill reports defects and targeted fixes. If the map shows systemic breakage (more than half of top tasks BURIED), say so in one sentence and recommend a separate IA project — do not start one.
Respect the 3-click threshold as a flag, not a law. A 4-click path that is obvious and linear is a lower priority than a 2-click path nobody finds. Report both, rank accordingly.
Do not modify product data during traversal. Use read-only paths where possible; if a task requires creating an object, use clearly labeled test data and note what you created.
Map each role separately. Never merge roles into one map — permission-gated items produce false dead ends.
If a screen fails to load or errors, record it as UNREACHABLE with the error, do not retry more than twice, and do not guess what it contains.
If analytics are unavailable, state this once in the output and use task-list order for frequency. Do not invent traffic numbers.
Cap the deliverable at the scope you froze in step 1. If you find defects outside scope, list them under "Out of scope, observed" without analysis.

Output format

# Navigation Flow Map — [Product Name]

Scope: [roles mapped] | [entry points] | [N screens traversed] | [date]
Analytics available: [yes / no — frequency proxy used]
Task list source: [provided by team / assumed by mapper]

## 1. Click depth per top task

| # | Task | Role | Entry point | Obvious path (clicks) | Shortest path (clicks) | Status |
|---|------|------|-------------|----------------------|------------------------|--------|
| 1 | [task] | [role] | [screen] | [n] | [n] | OK / DEEP / BURIED / HIDDEN |

Path detail for non-OK tasks:
- **[Task]** ([status]): [Entry] → [Screen] → [Screen] → [Target]
  Where it breaks: [specific label, screen, or missing link]

## 2. Defects

### D1 — [Dead end / Trap loop / Buried task / Label mismatch / Orphan]
- Screen(s): [name + URL/ID]
- Role: [role]
- Observed: [what happens when a user follows the obvious path]
- Impact: [which top task(s) this blocks or slows]
- Fix: [concrete structural change]
- Click count after fix: [n] (from [n])
- Requires product decision: [yes — question / no]

### D2 — ...

## 3. Priority order

| Rank | Defect | Type | Affected task | Effort estimate |
|------|--------|------|---------------|-----------------|
| 1 | D[n] | [type] | [task] | S / M / L |

## 4. Navigation inventory

[Role name]
- [Label] → [Destination] (depth [n])
  - [Label] → [Destination] (depth [n])

Unreachable screens: [list or "none"]
Orphan screens: [list / "not detectable — no route reference provided"]

## 5. Out of scope, observed
- [one line each, no analysis]

## 6. Open questions for the team
- [question requiring a product decision]

Failure modes

You map the intended structure instead of the real one. Reading a sitemap or route file and writing it up as a flow map produces a document that contradicts what users experience. Check: for every path in your output, you must be able to name the screen you saw at each step. If you cannot describe the destination screen's content, you did not visit it — remove or re-walk the path.

You count clicks as a power user. Using URL entry, keyboard shortcuts, or memory of where things live produces artificially low counts and hides the discoverability problem. Check: for each task, ask "would someone who has never used this product take this exact path from the labels alone?" If no, your obvious-path count is wrong — re-walk from the entry point using only visible labels.

You flag every 4-click path as a defect and bury the real problems. A long list of threshold violations with no ranking is unusable, and teams ignore it. Check: your priority table must have fewer than 10 rows in rank 1–5, and the top three must all block or seriously slow a named top task. If your top three are all minor depth violations, re-prioritize using impact, not click count.

You miss role-specific breakage by mapping only the admin account. Admin accounts see everything, so permission-gated dead ends never appear. Check: count the rows in section 4 per role. If any two roles have identical inventories, verify you actually logged in as each — identical navigation across different permission levels is rare and usually means you mapped one account twice.

License

MIT

navigation-flow-mapper