Skip to content

Map Navigation User Test

Empirical usability review — instantiates Knowledge Map Navigation

A usability test that hands real users a goal and watches whether the map actually gets them there — turning wayfinding failures into evidence for revision.

A Map Navigation User Test is the empirical check on whether a knowledge map works for the people meant to use it. You give a real user a concrete navigation goal ("find how to reset a locked account"), watch them try to reach it using the map, and record where they hesitate, backtrack, take a wrong branch, or give up. Its defining trait is that it validates the map against observed behaviour rather than the mapmaker's intuition — it is the only mechanism in the set that generates evidence about the map instead of being a map. Every other artifact here is built on someone's belief about how users will move; this one closes the loop by testing that belief, and its output feeds revisions back into whichever map was under test.

Example

A software company's help centre looks beautifully organized to the team that built it, yet support tickets keep asking things the docs clearly cover. They run a Map Navigation User Test. Five real users are each given the same goal — "you're locked out; find how to get back in" — and observed as they navigate. Using a first-click test,[1] the team records where each person clicks first, since that early choice strongly predicts whether they'll succeed. Four of five click "Account Settings"; the reset guide lives under "Security." The users aren't confused about their goal — the map's labels point the wrong way. The test also captures each user's starting knowledge (do they already know the company's term "credential recovery"? none did), which explains the miss. The team relabels the section and the tickets drop. No amount of internal review had caught it, because the builders knew where the page lived — the whole point of the test is that the users don't.

How it works

  • Assign a real navigation goal. Give users a concrete destination phrased in their terms, not the map's, and let them find it using the map alone.
  • Observe the attempt, don't guide it. Watch first clicks, paths taken, backtracks, dead ends, and abandonment — the behaviour, not the user's after-the-fact explanation.
  • Record the starting state. Note what each user already knows (vocabulary, mental model), since a "failure" often traces to a mismatch between the map's language and the user's.
  • Feed findings back. Convert observed failure points into specific revisions to the map under test, then re-test to confirm the fix — the validation loop.

What distinguishes it from its siblings is that it produces evidence about a map's usability; it authors no structure of its own and is agnostic to which sibling map it tests.

Tuning parameters

  • Task realism — goals phrased in users' own words test true findability; goals phrased in the map's language flatter the map and hide its worst failures.
  • Participant fidelity — testing genuine target users surfaces real mismatches; testing insiders or proxies is cheaper but reproduces the builders' blind spots.
  • Observation depth — rich methods (think-aloud, screen capture) explain why users fail but are costly; lightweight metrics (first-click success, task completion) scale but only show that they failed.
  • Sample size — a handful of users catches the big, common failures fast; larger samples are needed to measure rates and catch rarer breakdowns.

When it helps, and when it misleads

Its strength is catching the failures builders are constitutionally blind to: once you know where a page lives, you cannot un-know it, so the people who made a map are the worst judges of whether a stranger can navigate it. The test replaces "it's obvious" with observed behaviour, and even a few users expose the largest problems.

Its failure modes come from testing the wrong thing or the wrong people. Artificial tasks and insider participants produce reassuring results that don't transfer; tiny samples reveal what breaks but not how often. The classic misuse is running the test to ratify a map already shipped — designing tasks the map is known to handle so the results endorse it — rather than to find where it fails. The discipline is to phrase goals in users' language, recruit genuine target users, treat every observed failure as a finding rather than user error, and actually feed fixes back and re-test rather than filing the report.

How it implements the components

A Map Navigation User Test fills the archetype's validation slots:

  • navigation_goal — it supplies each participant a concrete destination to reach, phrased in the user's terms.
  • navigation_validation_loop — observing attempts, extracting failure points, feeding revisions back, and re-testing is the loop.
  • user_state_marker — it records each user's starting knowledge, since many navigation failures are really map-to-user language mismatches.

It authors no structure of its own — it does not build entities and relations (concept_node, relation_edge — that's Concept Map / Knowledge Graph), lay routes (navigation_path, alternate_route — that's Documentation Navigation Map), or track gaps (gap_marker, map_steward — that's Knowledge Gap Register); it tests the maps its siblings build.

Notes

This is the archetype's feedback mechanism: it doesn't produce a map, it produces evidence about one and drives its revision. It pairs naturally with any of the map-building siblings — the maps encode a hypothesis about how users navigate, and this test is how that hypothesis is checked against reality rather than assumed.

References

[1] First-click testing is an established usability method resting on the finding that whether a user's first click is toward the right area strongly predicts whether they'll ultimately complete the task — which is why an early wrong turn is treated as a map problem, not a user problem. ↩