By the end of the lesson, you can formulate what questions the navigation has to answer, you know the common navigation patterns, you can decide when search brings real value, and you can adapt the result, filter, and zero-result states to the user task.
Why are navigation and search separate?
The sitemap shows what is where. Navigation and search solve how the user gets there. The two are not alternatives of each other but supplementary tools: navigation is needed for browsing and for learning the system, search for quickly reaching something already known. A good product offers both, in a proportion adapted to the task.
Orientation in the system
Orientation is the user's knowledge of their own place and possible next steps. We distinguish three levels of navigation:
Primary navigation: shows the most important entry points of the system. It contains the frequent, high-value entry points.
Secondary navigation: gives room to rarer but necessary details.
Local navigation: helps within a section (for example pagination, filter, tabs).
Do not try to make all content equally visible in one giant menu. The goal of navigation is not to present the structure of the whole system, but to support the next meaningful decision.
Common navigation patterns
Pattern
When is it good?
What to watch for?
Top menu bar
On desktop, with few (3–7) main items
Does not fit on mobile
Bottom tab bar
On mobile, 3–5 equal, frequently used areas
No more than 5; always show which one is active
Hamburger menu
When there are many less frequently used items
The items are hidden, so they are found less often
Side menu
In admin and multi-level interfaces, on desktop
Takes up width
Breadcrumb
To show the location in a deep hierarchy
Does not replace the main navigation
Tabs
Switching views within a page
Only one view is visible at a time
The choice is not a matter of fashion. In a mobile Mai program meant for fast use, the bottom tab bar puts the frequent actions where the user's thumb is ("Tonight", "Saved", "Account").
When is search needed?
Search is especially useful when there is a lot of unique content, the user is looking for a known name or expression, or several equally important paths exist. It does not, however, cure bad labeling. If the user does not know the name of the thing they are looking for, a search field alone is not enough; in that case categories, examples, recommendations, or question-based entry points can help.
Plan what happens when typing (suggestions), with a misspelling (typo tolerance), with too many results (filtering, sorting), and with zero results.
Result list and filters
A filter is a control for narrowing results by one or more properties. Filtering is good if it is built on decision criteria the user actually uses. In an event finder the date, location, price, and accessibility are relevant; the internal database category less so.
A result should show enough information for the user to judge whether it is worth opening. The title alone is rarely enough. Mark the active conditions of the search or filtering, and make it easy to undo them. If the system gives a personalized or ordered result, communicate that too: hidden logic can cause a loss of trust.
A zero-result state is a search result where there is no content to show for the conditions. (You learned about the general design of empty states in chapter 3; in search, zero results are especially common, and the user's feeling of helplessness can be reduced in a fairly simple way.) A good state keeps the search term, suggests a similar search, offers clearing the filters, and shows where to turn.
Worked example: the search and filter interface of Mai program
In Mai program the student rarely knows the name of an event, so search is secondary, and filtering and browsing are primary. The home page shows the list of "Tonight" events, with quick filters above them: "Free", "English-language", "No registration". The search field helps by name or organizer, but it is not the first step.
The result card: title, time, price, language, registration requirement; so the user can decide without opening it. If the filters together give zero results, the system says which filter narrows the most, and makes it resettable with one click.
Common misconceptions
Claim
Clarification
"If there is a search, good navigation is not needed."
Search is good for a known target; for discovery and learning concepts, structure is needed too.
"The more filters, the more accurate the result."
Too many or poorly understood filters increase the burden and can hide the good result.
"The hamburger menu is always good on mobile."
It hides the navigation; if the main areas are few, a visible tab bar is better.
In brief
Navigation answers three questions: where am I, what is here, where next.
The navigation pattern adapts to the platform and the frequency of use, not fashion.
Search is a supplement, not the solution to bad labeling.
The result should show the data needed for the decision; zero results should give a next step.
Review questions
Where am I, what is here, where next: how does your project's navigation answer these?
In which task would the user search for a known name, and in which would they rather browse?
What would your result list show next to the title?
Navigation and search
Objectives
By the end of the lesson, you can formulate what questions the navigation has to answer, you know the common navigation patterns, you can decide when search brings real value, and you can adapt the result, filter, and zero-result states to the user task.
Why are navigation and search separate?
The sitemap shows what is where. Navigation and search solve how the user gets there. The two are not alternatives of each other but supplementary tools: navigation is needed for browsing and for learning the system, search for quickly reaching something already known. A good product offers both, in a proportion adapted to the task.
Orientation in the system
Orientation is the user's knowledge of their own place and possible next steps. We distinguish three levels of navigation:
Do not try to make all content equally visible in one giant menu. The goal of navigation is not to present the structure of the whole system, but to support the next meaningful decision.
Common navigation patterns
The choice is not a matter of fashion. In a mobile Mai program meant for fast use, the bottom tab bar puts the frequent actions where the user's thumb is ("Tonight", "Saved", "Account").
When is search needed?
Search is especially useful when there is a lot of unique content, the user is looking for a known name or expression, or several equally important paths exist. It does not, however, cure bad labeling. If the user does not know the name of the thing they are looking for, a search field alone is not enough; in that case categories, examples, recommendations, or question-based entry points can help.
Plan what happens when typing (suggestions), with a misspelling (typo tolerance), with too many results (filtering, sorting), and with zero results.
Result list and filters
A filter is a control for narrowing results by one or more properties. Filtering is good if it is built on decision criteria the user actually uses. In an event finder the date, location, price, and accessibility are relevant; the internal database category less so.
A result should show enough information for the user to judge whether it is worth opening. The title alone is rarely enough. Mark the active conditions of the search or filtering, and make it easy to undo them. If the system gives a personalized or ordered result, communicate that too: hidden logic can cause a loss of trust.
A zero-result state is a search result where there is no content to show for the conditions. (You learned about the general design of empty states in chapter 3; in search, zero results are especially common, and the user's feeling of helplessness can be reduced in a fairly simple way.) A good state keeps the search term, suggests a similar search, offers clearing the filters, and shows where to turn.
Worked example: the search and filter interface of Mai program
In Mai program the student rarely knows the name of an event, so search is secondary, and filtering and browsing are primary. The home page shows the list of "Tonight" events, with quick filters above them: "Free", "English-language", "No registration". The search field helps by name or organizer, but it is not the first step.
The result card: title, time, price, language, registration requirement; so the user can decide without opening it. If the filters together give zero results, the system says which filter narrows the most, and makes it resettable with one click.
Common misconceptions
In brief
Review questions