Mobile Menu UX, From the Icon to the Closing Tap
Most problems in a phone menu happen while it opens and closes, more than in the list itself. The icon and its label, tap targets, what the menu holds and in which order, where the focus goes, and why the main action also belongs outside the menu.
Mike Lopez
Designs and builds websites and B2B software
On this page
I think mobile menu UX is mostly decided by four things, an icon which people recognise and can hit with a thumb, a short list in the order that visitors need it, a menu which takes the keyboard focus when it opens and hands it back when it closes, and a main action which also sits outside the menu where nobody has to look for it. The menu on this website is a full screen panel behind two bars in the top corner of a phone, and building it taught me that most of the problems which visitors meet in a phone menu happen while it opens and closes, more than in the list itself.
This post goes through the menu in the order that a visitor uses it, from spotting the icon to leaving the menu again, with the choices which I made on this site and the ones which I would make differently for another kind of website.
The icon and its label
Most visitors know the menu icon by now. Nielsen Norman Group’s 2025 article on whether the hamburger icon is recognisable found that most participants read the classic three lines as the main menu, even with the word Menu taken away, as long as it sat in the top-left corner where people look for it. The same article still recommends the word Menu beside the icon, mostly for less experienced visitors and for layouts which they do not know, and it suggests the classic design over creative variations.
The icon on this website is two bars of different lengths in the top-right corner, which is a creative variation in an unexpected place by that study’s standards. I chose it for a portfolio whose visitors are mostly people who work on websites, and the button carries the words Open menu for screen readers. For a clinic, a shop or any website whose visitors are older or less used to phones, I would place three lines at the top left and put the word Menu beside them, because the visible word costs nothing and removes the guess.
A button big enough for a thumb
The icon’s drawing can be small, but the area which answers a tap should be generous. WCAG 2.2 sets 24 by 24 CSS pixels as the minimum at level AA, its enhanced criterion asks for 44 by 44 at level AAA, and Apple’s Human Interface Guidelines list 44 by 44 points as the default control size on iOS. On this website the two bars sit inside a 44 by 44 pixel button, aligned to the right edge so the icon lines up with the page margin while the tappable area reaches inwards.
The links inside the open menu follow the same rule, and each one is a row at least 44 pixels tall in large type, which leaves no small text links for a thumb to miss.
What the open menu holds, and in which order
A phone menu works best as a short list which the visitor can read at a glance, with the pages which most people came for at the top. On this website the open menu shows the logo and the light and dark switch along the top, then Capabilities, Projects, About, Journal and Resume, and then a full-width Send me an email button at the foot. Capabilities is a group which folds out its six pages in place when you tap it, which I wrote about in my post on dropdown menu UX, so the list stays at five lines until the visitor asks for more.
| Part of the open menu | What it holds | Why it sits there |
|---|---|---|
| Top row | Logo, mode switch, close button | The close button sits exactly where the open button was |
| Main list | Five pages, the most visited first | Short enough to read without scrolling |
| Groups | Sub-pages which fold out in place | The list stays short until the visitor asks for more |
| Foot | The main action as a full-width button | It is the one thing which every page leads to |
I would keep secondary links, such as the privacy notice, social profiles and legal pages, in the footer of the page, because each extra line in a phone menu pushes the important ones further from the thumb.
Opening the menu, and where the focus goes
When the menu opens it covers the page, so for a keyboard or screen reader visitor it behaves like a dialog. The W3C’s modal dialog pattern moves the focus to an element inside the dialog when it opens, keeps Tab cycling through the dialog’s own controls, closes it with Escape and returns the focus to the element which opened it. The menu on this website does each of those, and the open button tells screen readers whether the menu is open through aria-expanded, which the disclosure pattern describes.
The page underneath also stops scrolling while the menu is open, which keeps a visitor from scrolling the page behind the panel by mistake and losing their place.
Closing it so the page is really gone
A closed menu should be gone for every visitor, including those using a keyboard, and an early version of this website hid the menu by making it invisible, which left the focus unable to reach the menu when it opened again. The menu now uses the HTML hidden attribute, which MDN’s page on the hidden attribute describes as hiding the element from every presentation, screen readers included. The same page also explains the trap which I met next, that a CSS display value on the element overrides the attribute, so the menu’s own stylesheet has a rule which keeps it hidden whenever the attribute is present.
The two bars turn into an X as the menu opens, and the close button sits in exactly the same spot as the open button, which makes the change read as one icon turning into another. Tapping any link in the menu also closes it, so a visitor who goes back to the previous page sees the page and not the menu still covering it.
Keep the main action outside the menu too
Anything inside a menu needs one extra tap to be found, and NN/g’s research on discoverable mobile navigation found that 89% of participants used the navigation on a site which showed part of it on the page, against 44% on a site which hid it all behind an icon. So the main action on a phone should also sit on the page itself, and on this website the Send me an email button appears in the hero on the home page and in the closing panel at the end of every page, as well as at the foot of the menu.
On a clinic or a shop I would do the same with the booking or the basket, and I would show the two or three most used pages as visible links on the home page, which makes the menu a backup for most visitors and the main route for only a few. You can try this website’s menu from any page on a phone, such as Projects.
For the buttons inside and around the menu, my post on website button hierarchy covers why the main action takes the solid style and everything else stays quieter.
Frequently asked questions
Should a mobile menu icon have a label?
I think the word Menu beside the icon is worth adding on most websites, especially where visitors are less used to phones. NN/g found that most people recognise the three lines on their own, but the word removes the last doubt.
How big should a mobile menu button be?
At least 44 by 44 pixels for the tappable area, which matches Apple’s default control size and WCAG’s enhanced target size. The drawing of the icon can be smaller inside that area.
Where should the mobile menu icon go?
The top-left corner is where NN/g’s participants looked for it first. A top-right icon works too, but I would add the word Menu beside it to make up for the less expected place.
What should happen when a mobile menu closes?
The menu should disappear for every visitor and the focus should return to the button which opened it. Escape should close it, and tapping a link inside it should close it as well.
Should the call to action go inside the mobile menu?
It can sit at the foot of the menu, but it should also appear on the page itself, because anything inside a menu needs an extra tap before visitors see it.
