Design Navigation from the Inside Out
Don’t make people hunt through menus first. Let them ask for what they want, build it instantly, then save common paths as navigation items later. Read: “Everything Starts Out Looking Like a Toy" #294
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: imagining what interfaces might look like in the age of AI. Today, it looks like science fiction, but not too far in the future.
Edition 294 of this newsletter is here - it’s March 2, 2026.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ Design Navigation from the Inside Out
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.
Links for Reading and Sharing
These are links that caught my 👀
1/ In branding, have an opinion - “Different” is often more memorable than “better.” Review this branding masterclass.
2/ You can’t stop scrolling - Here are a few of the reasons why short form video content is so hard to put down.
3/ Time to get better at AI - Whether you like AI or not, it’s here to stay. Time to get better at it.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.