Persistent Navigation | LlamaPress Pattern Catalog
LlamaPress
Orient
Pattern

Persistent Navigation

A navigation surface that is present and identical on every screen, so "where can I go" never has to be answered by the page itself.

Orient

Without a fixed navigation surface, every screen has to solve wayfinding on its own. People fall back on the browser Back button, which means the app has stopped navigating for them, and any screen reached by a direct link becomes a dead end.

Live demo — try it Open full screen
Use when
  • The app has more than about three destinations.
  • People arrive on inner pages from links, bookmarks or email.
  • Anyone will use the product more than once.
Avoid when
  • The product is a single focused task with one exit, such as a checkout or a signup wizard, where a nav is an invitation to abandon.
  • The screen is a full-canvas editor and the chrome would compete with the work. Even then, keep a way out.

Anatomy

┌──────────────────────────────────────────────────────────────┐
│ ▤ Acme Ops   Jobs   Customers   Invoices   Reports    ⚙ ▾  │
│              ═════                                           │
└──────────────────────────────────────────────────────────────┘
   ↑ home link  ↑ ranked by frequency        ↑ rare things pooled
                ═ current section, marked with weight + rule

Three obligations, and the third is the one that gets dropped:

  1. Identical placement on every screen, including errors, empty states and modals-turned-pages. A nav that moves is not persistent.
  2. Ranked contents. Order is a design decision, not the order features shipped in.
  3. A visible current state. This is the cheapest orientation available and the most commonly skipped. Without it the nav says where you can go but not where you are.

Why it works

It converts wayfinding from a per-screen problem into a solved constant. Once a person has learned the nav — which takes one session — every screen in the product inherits that learning for free. That is the highest-leverage consistency in an application.

It also makes deep links safe. Someone landing on a record from an email is not stranded, because the same nav is there as on the home screen.

The ranking is where the real judgment sits, and it is the surface, don't bury principle applied to the top level: prominence equals frequency times importance. Depth for rarely-used things is correct, not a bug.

Getting it wrong

  • The org chart in the navbar. Sections named after internal teams, so every user has to learn your structure to find their task.
  • Fourteen flat items. Everything promoted, so nothing is.
  • Current state by colour alone. Fails in greyscale and for anyone who does not perceive that hue difference. Add weight or a rule.
  • A nav that hides on scroll and does not come back predictably. Now reaching it is a gesture people have to discover.

Exemplars

Linear keeps a narrow, quiet sidebar that never moves and never competes, with the current item marked by background rather than colour saturation. It demonstrates that persistent does not have to mean prominent.

Stripe shows the ranking done honestly: Payments, Balances, Customers at the top level, and a genuinely large surface of configuration deliberately pooled under Settings. Most products would have promoted several of those.

The extractable rule: a navigation bar is a published ranking. Whatever is in it, you are asserting people need often. If that assertion is not true, the bar is costing attention on every screen in the product.

Instead of this, consider

Same problem, different trade-off. Pick on the condition, not on taste.

Command Palette
When: Expert users jump around constantly and a menu cannot hold everything they reach for.
Breadcrumbs
When: The structure is deep and hierarchical; breadcrumbs answer "how did I get here", nav answers "where can I go".

Ask Leo for this

Paste this into your Leo chat. It describes the behaviour, not the code, so Leo can fit it to your data.

Prompt
Give this app one persistent navigation bar, rendered from a single shared
layout so every page gets the same one.

- Put the destinations in it ranked by how often people use them, most
  frequent first. Rare things like settings and admin go in a menu at the end,
  not in the main row.
- Keep it to about seven top-level items. Past that it is a list to read, not
  navigation.
- Mark the current section visibly — a different weight and a colour or an
  underline, not colour alone.
- Make the product name or logo a link to the signed-in home.
- Keep it in exactly the same place on every screen, including error and empty
  pages.
- On a narrow screen, collapse to a menu button, but leave the current section
  name visible so the person still knows where they are.

Related

Wiki guide
UX Principles Guide for Building Web Software
The orientation principle this pattern exists to satisfy.
Pattern
Orientation
Where am I, how did I get here, where can I go next.