Design Navigation from the Inside Out

Instead of starting with a nav item, identify what users want

In 2023, I wrote about building software from cow paths. The idea was simple: study how people actually work and design around those natural paths. Don’t invent workflows in a conference room and expect users to adapt. Watch behavior, then pave it.

That assumed a sequence: behavior happened first, and design followed.

AI changes that. We no longer need to observe workflows outside the product and encode them later. The product itself can now surface paths before navigation hardens. What once formed in the real world can form inside the system.

The old model: navigation first

Most products still design from the outside in. Teams define objects, group features, build a left rail, and assign ownership to vertical slices. Navigation becomes the skeleton of the product. Users learn to translate goals into routes.

This works when attention is abundant and friction is tolerable. It breaks down when attention shrinks and abandonment rises.

On mobile, navigation carries real cost. Small screens compress hierarchy. Deep stacks create context loss. Each additional step increases the chance the user leaves. Navigation directly affects retention.

The shift: outcome first

Conversational interfaces changed how users begin. Instead of asking where something lives, users ask how to get something done.

When someone writes, “Build a Q4 churn breakdown by segment and export it for finance,” they define the task in one move. They do not think about Reports, Filters, or Export tabs. They think about completion.

A composable system can assemble the pieces around that intent. It generates the query, renders the visualization, exposes filters, and offers export without forcing the user across multiple surfaces.

Because orchestration remains observable, teams can measure which actions cluster together and which compositions correlate with successful outcomes. Navigation becomes something derived from behavior rather than imposed upfront.

“Reports” versus inline insight

Consider a team debating whether to add a top-level “Reports” tab. Users ask for analytics and exports, so the team creates a Reports page with filters, saved views, and export controls.

Now consider the alternative. A user types, “Show me churn by segment for Q4 and highlight anything unusual.” The system generates the chart inline, highlights anomalies, exposes filters beneath it, and offers export in context. The user adjusts the date range. The chart updates in place.

The report never lived in a silo. It emerged around the task.

If the conversation persists, the chart and refinements stay attached to that thread. The user can return later without navigating a dedicated Reports surface.

Over time, patterns emerge. Users often start with churn, segment by tier, adjust dates, and export. At that point, the team can promote those recurring compositions into structured surfaces.

In the traditional model, you create Reports first and hope users find what they need. In the inside-out model, reports emerge in context. Structure follows evidence.

Repeated discovery

Creation is only half the problem. Users also need retrieval. Eventually someone asks, “How do I find that churn report from last month?”

Inside-out design does not eliminate structure. It delays commitment.

One solution uses intent-driven retrieval. The user asks for the churn report they exported last week, and the system searches persisted conversations and restores the visualization.

Another solution adds faceted filtering across conversations. Users can filter by reports, exports, segments, or shared artifacts. Navigation becomes metadata over work instead of a fixed set of routes.

Creation flows horizontally. Retrieval relies on search and filtering. If certain patterns dominate, a dedicated Reports surface may still emerge. It just won’t start there.

Mobile and desktop pressures

Mobile-first users complete tasks and move on. They operate in short bursts. If the path feels long, they abandon.

Composable conversational layers compress friction. They resolve bottlenecks inline and reduce the number of surfaces users must traverse. Because abandonment happens quickly, teams get rapid feedback on which compositions succeed.

Desktop users face a different problem. Mature products fragment into silos. Reporting, automation, and communication live in separate verticals. Navigation reflects ownership.

A horizontal composable layer cuts across those boundaries. The user expresses an outcome, and the system assembles capabilities across teams in a single flow.

Architecture and uncertainty

Teams must design discrete, callable actions, define clear state transitions, log orchestration patterns, and provide safe preview mechanisms. Without that foundation, conversation becomes a thin wrapper over static routes.

There is also an organizational question. Route-driven products often mirror team boundaries. Conway’s Law suggests systems tend to reflect the structures that build them. That relationship is common, though not deterministic.

Inside-out design cuts across those boundaries. Whether that reshapes organizations or settles back into silos remains unclear. What matters is that orchestration becomes measurable. Teams gain visibility into how value forms across functions.

This will challenge support

Support teams used to page-based troubleshooting will need to reason about compositions rather than routes. That shift can feel uncomfortable, but variability is not chaos if instrumentation exists.

Product evolution often precedes operational comfort. When architecture improves, teams adapt. The right move is not to preserve familiarity but to make new behavior observable and teach teams how to interpret it.

What’s the takeaway? If navigation slows users down, compress it. If composable intent layers reduce friction, ship them. Then measure what changes.Let the path form inside your product before you pave it.

gregmeyer
gregmeyer
Articles: 574