Design patterns
Mobile app navigation design: choose destinations before icons
Plan mobile navigation around stable destinations, distinguish actions from locations, and review back behavior and small-screen states.
Name the places people return to
Start mobile navigation with the destinations users need repeatedly. For an illustrative field-service app, those might be Jobs, Schedule and Messages. Creating a job is an action within that structure; it does not automatically need its own permanent destination.
Write a plain-language description for each destination. If two descriptions overlap, clarify the information architecture before choosing icons. An attractive navigation bar cannot resolve uncertainty about where a person should find an assigned job.
Keep a route map beside the mockup
Map a typical path: Jobs, a job detail, an attached photo and back to the same job. Decide what back means at each point and whether list filters survive the return. Also decide how a notification opening a job fits into the hierarchy.
Do not make the visual selected state depend on where the user first entered. The location and its parent should remain understandable after a deep link, a refresh or a return from another application. For a mobile web app, test browser history as well as in-app back controls.
Borrow the behavior that fits your platform
Use Taste references to compare labels, destination hierarchy and the relationship between list and detail. Keep platform conventions in mind rather than reproducing an unrelated app’s gestures. A screenshot can suggest the placement of a control, but it cannot prove the swipe or back behavior.
For web interfaces, distinguish navigation links from an in-page tabs widget. The WAI-ARIA tabs pattern describes panels within a view and has its own keyboard behavior. Do not add tab roles to ordinary route links simply because the navigation looks like a row of tabs.
A brief for the navigation model
Keep this prompt focused on routes and behavior before asking the agent to restyle every screen.
Review navigation for our field-service app. The recurring destinations are Jobs, Schedule and Messages. Map list-to-detail routes, deep links and back behavior before changing visuals. Use my Taste mobile references to discuss hierarchy and labeling. Keep create-job as an action unless the workflow justifies a separate destination. Preserve filters when returning from a job. For web routes, use links and appropriate current-page semantics rather than treating every destination as an ARIA tab.
Test the awkward paths
Try long labels, a large text setting, an unread message count and a device with limited vertical space. Open a detail from outside the app, then navigate back. Check whether the active destination remains recognizable without color alone.
If a destination contains a long list of unrelated tools, reconsider its purpose. Moving everything into “More” may hide an information architecture problem rather than solve it. Test the labels with users who do not know the internal feature names.