November 8, 2026

How to Review a Mobile Menu

Review your mobile website menu’s labels, groups, and levels, then compare alternatives that keep navigation, Back, Close, and current location clear.

A silver compass sits beside a phone on an orange background. The phone screen shows a Back to Shop link and a Close control above a Sneakers heading, with Everyday Sneakers highlighted, then Running, Court, and View All Sneakers.
In this guide

Someone who knows the Sneaky Sneaker Store may find Everyday Sneakers without thinking about the route. A new visitor sees a small menu symbol, opens a panel of equally styled links, and has to work out which choices lead to products and which tell the company’s story. The menu opens, but does it give useful direction?

Review the current menu through a customer’s task, including the changes between closed, open, nested, and reopened states. Then compare relevant design examples and ask for an alternative that solves the specific confusion. A different menu style is useful only if it helps people understand your actual choices. To set up comparable phone, tablet, and desktop views, use the screen-size review guide.

We’ll use Sneaky Sneaker Store, a fictional shop. A shopper wants everyday sneakers for commuting and casual work. Its existing routes include Shop, Sneakers, Socks, and Shoe Care, with Everyday Sneakers, Running, Court, and View All Sneakers within Sneakers. These are illustrative labels, not a proven structure for every store.

For a first pass, open the menu, follow one branch, return to its parent, close it, and reopen it from the destination page. Record where the choices or controls become unclear; you can report that without choosing a replacement design.

Start With the Route the Customer Needs

Choose a useful destination without turning its menu labels into the task instructions. “Find sneakers for an everyday commute” lets someone interpret the choices. “Open Shop, then Sneakers, then Everyday Sneakers” tells them the answer before the review begins.

Look from a plausible arrival page and a deeper page, since the customer may not start at the homepage. Ask someone unfamiliar with the site to try the task if possible. Their attempt can expose a question your familiarity conceals, without proving how all customers will behave.

Keep this review about how the existing routes are presented. If the store’s product categories themselves need research, record that separately. Rebuilding the assortment is a different decision from making the menu’s groups and levels understandable.

Make Opening the Menu Explain What It Is

Look at the closed menu in its actual header. Can someone recognize the menu icon or “Menu” control beside the logo, images, and other controls as the way to open site navigation? If a small unexplained symbol is hard to identify, compare a clearer treatment, perhaps including the word “Menu.” Judge the resulting space and clarity rather than assuming a label always solves the problem.

Now open it. Can the shopper recognize site navigation, see the choices, and work out how to return to the page? An open panel that looks like a new page or promotional message may make the change harder to understand.

Full-screen and smaller panels have different tradeoffs. Neither is automatically right for every phone site. NN/g’s menu-design guidance is useful for judging labels, orientation, and manipulation without choosing a fashionable layout first.

Show Which Choices Belong Together

Imagine Shop, Everyday Sneakers, Our Story, Socks, Court, and Contact all appear in one flat list with the same treatment. The shopper has to infer which are product families, which are subdivisions, and which belong to another purpose.

Ask to compare clearer grouping of the existing shopping choices and the company-information or contact routes. Name what the grouping should explain. “Make the shopping routes distinct from company information” gives the designer a more useful question than “make the navigation cleaner.”

Follow one branch. If choosing Sneakers replaces the list with Everyday Sneakers, Running, and Court, the new panel should explain that these are choices within Sneakers. A heading such as “Sneakers,” with a distinct “Back to Shop” control, can make the level change explicit.

Check what the parent label actually does. Does Sneakers open a destination, reveal more choices, or offer separate controls for both? Ask the designer to demonstrate an unambiguous treatment rather than relying on a chevron whose behavior you are guessing.

Keep Back, Close, and Current Location Distinct

Back to Shop returns to a parent menu level. Close dismisses the menu and returns to the current page. If one unexplained icon appears to do both, record the state and the ambiguity before requesting a replacement.

After following a destination, reopen the menu. Can the shopper recognize the current page or branch and choose a related route? A current-location cue can help, but the useful design depends on the menu. Do not require every site to remember every expanded branch forever.

Long menus need this attention too. Can the customer reach the choices and close control when labels wrap or the content grows? Check actual words rather than a short demonstration list.

Compare the Current Menu With Relevant References

Keep a screenshot or supplied sequence of the current menu beside the references. Name the question first: for example, can someone distinguish the Sneakers parent level, Back to Shop, and Close? Compare how an alternative explains those choices using a similar number of levels and similarly long labels.

Mobbin provides references from existing apps and websites, including screens and flows. Look for comparable web navigation and inspect the open and nested states actually available. A library reference is not a live interaction test, and not every example will show the state you need.

Dribbble offers designers’ shared work, which can include concepts rather than implemented menus. Use it to explore alternative groupings or visual treatments. Read the creator’s description before treating an image as a shipped design. “Mobile website menu” or “nested navigation” can be useful search phrases, not guaranteed filter names or a promised browsing path.

For our Sneakers panel, use either platform to compare how the menu identifies a parent, reveals a branch, and distinguishes Back from Close. Record the idea and which states are actually shown. If touch behavior, keyboard access, or the return route is absent, mark it unknown rather than assuming it works.

An accordion reveals choices beneath a group heading. It can keep neighboring branches visible but grow into a long panel. Sequential panels replace one level with the next, reducing simultaneous choices while hiding neighboring choices. That makes the current level and return route especially important. A few visible routes alongside a menu may suit a compact set of destinations, but can also create an unclear division between shown and hidden choices.

Bring your own labels and task to the comparison. Would longer names still fit? Would the shopper understand which products sit in the branch? Native-app references can suggest grouping ideas, but do not assume their gestures, navigation, or interaction behavior can be copied directly into a website.

Choose a reference because it answers the specific question. Ask the designer to compare that treatment with the current menu using your labels. A clearer parent heading or separate Close control may resolve the problem without rebuilding everything. A polished image or familiar brand is not proof of suitability for your customers.

Borrow the design question, not another team’s artwork or assets. Dribbble’s sharing guidelines require permission to reuse design work. Neither platform establishes your reuse rights or proves that the illustrated menu works on a phone.

Check the Interaction the Design Actually Uses

Open the page directly on a real phone to try nearby choices, longer menus, and the route back. A mouse in a scaled preview cannot establish touch behavior. On desktop, use Tab and Shift+Tab to follow the controls and check whether you can see where keyboard focus is.

Note any control you cannot reach or whose selected position you cannot see. Ask the developer or accessibility reviewer to confirm how names, open or closed states, and current-page information are conveyed. Ordinary website navigation does not automatically need the specialized interaction rules of an application menu. W3C’s disclosure-navigation example explains that distinction.

If the menu is implemented as a modal overlay that blocks interaction with the rest of the page until it closes, it needs the corresponding behavior, including moving focus into it, keeping interaction within it while open, and an appropriate way to close and return. The modal-dialog pattern gives the team that reference. A panel filling the screen does not, by itself, establish that it is modal.

Request a Specific Menu Comparison

Send the page address, customer task, browser or device, checked width and height, and menu state. Include the screenshot and explain what the visitor could not distinguish. For example:

At [page address], checked at [width × height], selecting Sneakers opens Everyday Sneakers, Running, and Court without a parent heading. The only return icon could mean Back or Close. Please compare a Sneakers heading, Back to Shop, and a separate Close control using these same labels.

Review the alternative by following the same route, including an incorrect branch and the return. Keep outstanding touch, keyboard, and assistive-technology checks assigned. The useful result is a menu whose choices and levels are easier to understand, not merely one that opens or resembles another company’s design.