Sticky Menus

Four teams each added one persistent element, and each one is defensible on its own. Together they leave a strip of article about the height of a paragraph, on a screen somebody opened to read.

Nobody designed that screen. Every element on it was designed, and the arrangement was not, because nothing in the process asks what the page has already spent.

A sticky menu earns its place on a page where people navigate while they scroll. That page exists, and it is rarer than the default suggests.

Anatomy of a Sticky Layer

Sticky is a property that gets applied to a component, so the pattern has no single form. Naming what can hold it, and how hard, is what makes the decision discussable.

What Gets Pinned

Seven components take the property, and they are not equally defensible.

The global header. A section navigation or tab strip. A filter bar on a list. The header row of a table. A footer action bar holding the primary action on a phone. A sidebar carrying a long menu. And a back-to-top button, the smallest of them and the easiest to justify.

Alongside those sit the things that are not navigation at all: a promotional banner, a cookie notice, a newsletter prompt, an app download nag. They use the same mechanism and compete for the same edge.

Three Degrees of Persistence

The choice is not only whether to pin something.

Always visible holds the bar in place through every scroll, and pays for it on every screen. Partially persistent hides the bar on a downward scroll, because somebody scrolling down is reading, and returns it on an upward scroll, because somebody scrolling up is looking for something. Friedman recommends a 300 to 400ms transition for that return, fast enough to arrive when wanted and slow enough to avoid flashing. Not pinned at all is the third, and it is the correct answer more often than a design system implies.

The Queue for the Same Edge

Every pinned element competes with the browser's own furniture.

The address bar, the tab strip, the system status bar and the on-screen keyboard all take from the same screen, and none of them are in your file. Friedman shows the result on Sverigesradio and TV Gids, where several sticky menus chain together down the screen. What makes this hard is ownership: the header belongs to design systems, the promo to marketing, the cookie bar to legal, the app prompt to growth.

What That Means for the File

The stacking never appears in a design review, because each element is reviewed alone.

So the artifact worth producing is one frame showing every persistent element at once, at the smallest supported size, with the keyboard open. That frame is the argument, and the pixel counts behind it come next.

Pro tip: List the persistent elements on your busiest page and write the team that owns each one beside it. If the list has four owners, the screen has no owner, and that is the finding to take to the review.