wiki Paths

Route expertise

Route expertise is what a team knows about getting a user from where they start to where they're trying to go: not just that a route exists, but the good ways to travel it, where it forks, where people get stuck, which stretches are worth the effort. It's the knowledge a mountain guide builds up after climbing the same trail many times, knowing the switchbacks, the waystations worth recommending, how hard each stretch really is. The guide hasn't done the hiker's climbing for them; the guide has just done the route-finding the hiker would otherwise have to work out alone.

Definition

Route expertise

Route expertise is the team's knowledge of the user's transition — the route through it and the modes of traversing it well — that the team externalizes into affordances for users to integrate during their own traversal.

What route expertise contains

The knowledge has two parts held together. One is knowledge of the route: where the user starts, what they're trying to reach, and what lies between — most of which runs outside the app. The other is knowledge of how to traverse that route well: which moves convert effort into progress, which steps reliably trip people up, where the route forks and which fork serves which user.

How a team acquires this knowledge is a separate discipline — following the tracks, watching users' actual trajectories through the transition rather than reasoning about them from inside the office. Route expertise is the knowledge itself: the thing that discipline produces, and the thing the team prepares to hand to users.

Externalization and integration

The handoff happens in two moves at two different times. At construction time, the team externalizes its route expertise into affordances — turning what it knows about the route into defaults, sequencing, warnings, markers, and recommendations built into the offering. At runtime, each user integrates those affordances into their own traversal, getting the efficacy benefit without having to develop the expertise first.

The team does the figuring-out-the-route work once and bakes the result in; every user after that draws on it. What the team externalizes, users can reach for; what the team leaves un-externalized, each user has to work out alone. A mountain guide who has climbed the trail many times can mark the switchbacks, rate the difficulty, and flag the unstable scree — and a hiker reading those markers skips the route-finding without skipping the climb. The guide hasn't climbed the trail for the hiker; the hiker still climbs.

A low starting threshold

The framework doesn't require world-class expertise before a team can start. A team that is a couple of steps further along the route than its users can already externalize something useful — the markers it can place are the ones it has earned by going a little further than the people following it. What the framework asks for is a direction, toward deeper expertise over time, and a discipline, turning that expertise into affordances rather than letting it sit in the team's heads. The expertise grows; the externalization happens continuously as it does.

Example

A team running a payments SaaS has watched thousands of users connect their first bank account. They know the connection fails most often when users pick the wrong account type, that the verification step confuses people who expect it to be instant, and that users who reach a confirmation screen come back the next day while users who don't tend to drop off. That accumulated knowledge is route expertise. The team externalizes it: the account-type field defaults to the common choice and warns on the rare one, the verification step now states how long it takes and why, and a confirmation screen fires the moment the connection goes live. A new user setting up their first account integrates all of that in a single sitting — they get a working connection without having to learn, the hard way, what the team learned across thousands of accounts.

See also