Make the product easy to navigate
Organize routes, labels, and user flows around recognizable tasks and stable URLs.
Why this matters
Picture someone opening your product thinking "where do I approve this?" Information architecture is how they guess right. A sitemap lists the places; a flow shows how a person moves through them to finish a job. Get this wrong and every screen costs extra hunting.
What to understand
Start with the words people actually use and the jobs they do most. Your database has record types; your navigation needs labels people recognize. A "Request" might belong under work awaiting a decision, not in an abstract list of every record type.
Code-only route groups can tidy your files without changing the URL. They don't lock anything — what you're allowed to do still has to be checked on the server, for direct links and server requests too.
Watch for
- Too many sections or vague labels in top navigation; deep nesting hidden on small screens.
- Breadcrumbs used instead of clear main navigation; links styled as tabs when the tab behavior doesn't fit.
- Filters or views that die on reload because they never made it into the URL.
- Passwords, tokens, or private drafts leaking through URLs, history, logs, or pasted links.
- Renaming a URL by hiding the page from the menu — bookmarks and incoming links still break.
- A blank page standing in for a finished not-found or no-access state.
Strong default
Use real links for moving between pages. Put non-sensitive filters, sorting, and page position in the URL's search parameters so sharing, reload, and back/forward keep the view. Check submitted values, keep secrets out of URLs, and never follow an arbitrary submitted address blindly after sign-in.
When this doesn't apply
A sidebar is not mandatory for a deep product, and search is not a substitute for discoverable navigation. Match the pattern to depth and frequency: a few broad areas get top navigation, constant movement among many tasks earns a sidebar, a command menu suits people who already know what they're after — not people still learning what's there.
In practice
Public
/ product explanation
/help task guidance
Workspace
/requests work to review
/requests/:id one request and its history
/settings/members membership and roles| Pattern | Useful when | Watch for |
|---|---|---|
| Top navigation | A few broad areas need equal visibility. | Too many sections, vague labels. |
| Sidebar | People keep moving among many tasks. | Deep nesting, hidden on small screens. |
| Breadcrumbs | Knowing where you are in a hierarchy matters. | Using a trail instead of clear main navigation. |
| Tabs | Related views share one context. | Styling links as tabs when the tab behavior doesn't fit. |
| Search or command menu | People know what they're after. | Forcing discovery through exact words. |
Trace the task beyond the happy path. Take "approve a request" past the happy path: how you get there, the context you see, the decision itself, the saving state, where success lands, what no-access looks like, what a conflict looks like, what happens if you're interrupted. Decide what you can get back and which layer guarantees it.
URLs outlive redesigns. Before you rename one, check incoming links, bookmarks, shared metadata, and search indexing. Keep the old one working or add a deliberate redirect.
Verify
Ask your agent: "show me this task's denied, missing, and interrupted states." Navigation should still help when something is missing or access changed.
Related skills
Use $sitemap for the places, $flow for a task, and $hierarchy for a page. Continue with layout patterns to give those relationships physical shape.
Last updated on