When the Assistant Becomes the Navigation

When the Assistant Becomes the Navigation

Why this matters

An assistant that can take you anywhere in the product, and increasingly just do the thing itself, doesn't sit inside the navigation model. It competes with it.

A designer asked the fair question about our AI assistant work: where's the revenue, and what comes after? A case for grading paradigm bets differently.

In a one-on-one this week, one of my strongest designers asked the question every leader should hope their people ask: this assistant work I’m leading, where’s the revenue, and what does the after state look like? He has the deepest context on the surface, his name is on the deliverables, and he couldn’t see the finish line. That’s a designer taking the business seriously, and it deserved a serious answer.

The honest answer is that he was grading the work with the wrong rubric, because we handed him the wrong one. An assistant that can take you anywhere in the product, and increasingly just do the thing itself, doesn’t sit inside the navigation model. It competes with it. The reframing I shared with him: this work may change what navigation is, not bury the menu under a chat box. If the assistant absorbs wayfinding, years of information architecture debt become smaller problems downstream, because fewer journeys depend on the hierarchy at all.

The best evidence I could offer wasn’t a metric, because paradigm bets don’t have metrics yet. It was a pattern. Tesla’s screen-only cabin felt wrong to almost everyone at first, and then it redefined what car interiors are. Figma’s auto layout confused its earliest skeptics into becoming its loudest advocates. Foreign first, obvious later is what a paradigm shift feels like from the inside, and a leader who demands this quarter’s numbers before making that kind of bet will only ever make iterations.

You can’t defend a paradigm bet with metrics that don’t exist yet. The evidence is the pattern, and the pattern says foreign first, obvious later.

The conversation then surfaced 2 obligations that leaders owe any paradigm bet. First, change management deserves more than tooltips and a launch email. Another team here is testing an animated walkthrough that shows users the new flow before they ever touch it, and that’s the level of effort a navigation shift demands. Users don’t cross paradigms on their own. You walk them across, and doing that well is what earns leadership the confidence to keep going.

Second, he asked how much user pushback we’d tolerate before retreating, and I didn’t have a crisp answer. I owe him one, and I’m getting it from my own leadership this week. Asking a designer to hold a paradigm bet without telling them where the org’s flinch point sits is asking them to absorb every wave of complaint personally. Name the tolerance in advance and pushback becomes data. Leave it vague and pushback becomes doubt, and doubt is what actually kills these bets.

The teachable part

When a bet changes what a surface is, stop grading it like an iteration. Defend it with patterns, invest in walking users across, and tell your team the flinch point in advance.

Filed under TR The Reframe — Assumptions, examined.