“Mobile-first” and “one structure fits every device” are both answers. Neither is the question. Where do people arrive, what are they trying to do there, and what does a failure cost? Settle those three and the set of defensible patterns becomes much smaller. Skip them and you are choosing a menu by taste.
Part 1 settled what a structure is. Form factor asks which screen that structure has to win on — and the honest answer is that only one thing is truly fixed. Call it the canonical architecture: the entities, their names, and what contains what. That never varies. What each device shows is a projection of it — a view that may be partial. An ATM exposes perhaps five of a bank’s fifty destinations, and is not thereby a different bank. A watch shows one alert. Neither invents a node the others lack, contradicts the containment, or renames anything. The test is not “can everything be reached from everywhere” but “does anything here mean something different from what it means over there.”
Two slogans compete for this decision and both skip it. “Mobile-first” is a genuinely good method for deciding what survives when space is scarce — it becomes insufficient the moment it substitutes for designing the environment where the work actually happens. “One structure for every device” is true of the architecture and false of the interface, which is how a hover menu reaches a tablet with no pointer to drive it. Both survive because the prior questions go unasked: where do people arrive, what are they doing when they get there, and what does it cost when they fail? A device can carry a fifth of the sessions and most of the consequences — a hospital phone is the clearest case, and no traffic chart will ever show it.
“Form factor” is shorthand for at least five things that move independently. Separating them is most of the work — a phone plugged into a monitor with a keyboard has a desktop’s screen, a desktop’s input and a phone’s operating system, and no device label describes it.
Screen room alone explains almost nothing. A television has more of it than any laptop and the worst navigation of the three, because its input is four directions and its reader is three metres away.
Device share is one input, not the answer. This weighs each task separately, against the measure that actually matters for your product — and it is allowed to conclude that you do not yet know.
Weighting is deliberately crude — its job is to stop one number deciding for you. Two cautions it cannot model: revenue credited to a desktop session often began as mobile discovery by the same person, so a conversion gap is partly an attribution artefact; and a low-traffic task can carry the highest consequence, which is why criticality sits in the table rather than in a footnote.
Same product, same structure, same job to do. Only the navigation changes — and with it what you can see, what your hand can reach, and how many moves the task takes.
No pattern wins every row, and real products almost never use one alone — the last option is a hybrid because that is what shipped software actually looks like. Treating these as mutually exclusive templates is itself the mistake.
Putting navigation behind a hamburger does not make it hard to find — everyone recognises the icon. What it removes is the prompt. NN/g measured content discoverability falling by roughly a fifth once navigation is hidden rather than visible1, and where a visible tab bar replaced a hidden menu people clicked around 9% more overall and roughly 30% more on the menu items themselves1. But the hamburger is only the most famous of ten hiding places, and treating it as the villain lets the other nine pass unnoticed.
A hidden command can be hard to discover and superb to execute. Photoshop’s shortcuts, a CAD command line, terminal flags, an IDE’s context menu — expert tools trade discoverability for density on purpose, because the same person will run the command ten thousand times. That trade is legitimate when two conditions hold: there is a discoverable route for the first time, and a fast route for every time after. The failure is offering only one of the two. Adaptive disclosure is how mature products serve both — labels and guidance for the newcomer, icons and keystrokes for the person who has earned them.
Architecture reaches people through an input vocabulary, not through a number of pixels. Hover is a desktop affordance with no touch equivalent, and Baymard found around 88% of large commerce sites using hover mega menus with roughly 60% omitting the 300–500ms intent delay that stops them flickering2. The browser will tell you what it actually has — hover: hover against hover: none, pointer: fine against pointer: coarse — and those answer the real question, which viewport width never does. A tablet with a keyboard reports differently from the same tablet held in two hands, and modern devices routinely offer touch, pointer and keyboard at once.
Voice removes the menu altogether. “Show my upcoming payments” still needs the architecture — the assistant has to map that phrase onto an entity, a task and a containment — but information scent becomes phrase prediction, confirmation and repair rather than a label on a door.
A breakpoint is where this composition stops working. So this lab does not hand you named bands — it reports what breaks, and you find the widths. The familiar ranges appear at the end, after you have seen where your own layout actually gave way.
A layout that holds at normal text and fails at 200% has its breakpoint in the wrong place. Same for a label that fits in English and wraps in German. Both are ordinary, both are found in ten seconds, and neither shows up when you only drag a window.
At least six layers compete for the same space, and naming them turns an argument about a menu into a set of separate decisions. Global is the top-level map. Local is siblings and your place among them — the layer most often sacrificed, which produces the specific complaint of arriving somewhere with no idea what else is nearby. Utility handles account, cart and language. Contextual lives inside the words. System is back, close, home, and returning from a deep link — usually the platform’s job, and the layer that breaks when an app fights it. And many products navigate by object rather than by section at all: a clinician moves between patients, an analyst between portfolios, a mechanic between vehicles. Section navigation is then a second axis inside the object, not the primary one.
The usual degradation order is a heuristic, not a law. Contextual first, then utility, then local collapses, with global surviving — that holds for most content products and fails plainly elsewhere. In a reading or learning product, contextual navigation is the experience: previous chapter, definition, related concept. On a single-purpose kiosk, global navigation barely exists. Derive the order from the task, then write it down so it is a decision rather than an accident.
A search result, a notification, a shared link, a QR code on a machine, an email, a widget, a voice command. Readers land deep in the structure having seen none of it, which means every destination has to answer five questions on its own: what is this, where am I, what is nearby, how do I go up, how do I get out. A page that only makes sense to someone who walked in through the homepage is a page most of your audience will never understand. This is also where deep-link entry earns its keep — a QR code on a pump that opens straight to that asset is excellent architecture, provided the page it lands on says which pump, which site, and how to reach the rest.
Start a mortgage application on a phone, finish the documents on a laptop. Find a recipe on a phone, cook from a kitchen display. Plan a route at a desk, drive it on a car screen. Continuity is an architecture problem before it is a sync problem: the destination needs a stable address, the same name on both devices, preserved state, an obvious handoff, and a way back. Where the names drift between devices — “Documents” here, “Files” there — the person is not continuing a task, they are starting a second one and hoping it is the same.
Eight products, eight different reasons the composition changes. Not one of them is “the screen is smaller.”
Three briefs, drawn from a bank of ten. Each asks for a primary pattern and a local-navigation treatment, because that is the shape of a real answer. Two briefs in the bank cannot be decided from what they tell you — saying so is the correct answer, not a cop-out.
Seven question formats, the way Beyond Dictionary serves them. Every question carries layered hints — a nudge, the reasoning, then a deeper connection — so a wrong answer opens a door instead of closing one.
The follow-on questions — the ones that arrive once the principle is agreed and the argument moves to what to actually ship.
The one your own numbers point at, weighted by both traffic and value. Global averages describe the internet rather than your audience: mobile is roughly 62–64% of worldwide traffic, but that figure spans e-commerce at about 71% mobile and B2B SaaS at about 35%. Pull your own device split for visits and for revenue, and design the composition that carries the most of both. Where they disagree sharply, neither device can be treated as secondary and you have two compositions to design rather than one.
No — one structure, several expositions. The architecture should be identical everywhere so that a shared link, a search result and a support answer all mean the same thing regardless of the device they open on. What varies is the navigation: a left rail on a wide screen and a bottom tab bar on a phone can express exactly the same map. The moment the structures themselves diverge, content starts existing on one device and not the other, and nobody notices until somebody follows a link that leads nowhere.
Reflowing cleanly means the layout fits, which is a smaller claim than it sounds. Reflow says nothing about whether primary destinations are reachable without opening a menu, whether tap targets survive, whether local navigation still exists, or whether anything depends on hover. Narrowing a desktop window checks one composition twice. A mobile design is a composition someone decided on, then verified at real widths — 360, 390 and 412 — with a finger rather than a pointer.
Because recognition was never the problem — the prompt is. NN/g measured content discoverability falling by roughly 21% when navigation is hidden rather than visible, and feature-discovery drops in the 30–50% range are widely reported. Where a visible tab bar replaced a hidden menu, users clicked around 9% more overall and roughly 30% more on the menu items. People navigate what they can see. That makes the drawer perfectly reasonable for utility and secondary items, whose cost of being forgotten is low, and wrong for the three or four things the product exists to do.
By widening your own layout until something breaks, then putting a breakpoint there. A breakpoint marks the width at which the current composition stops working, which is a property of your content rather than of anyone's device catalogue. Common ranges are a reasonable starting frame — roughly ≤380, 381–640, 641–1023, 1024–1439 and ≥1440 — but naming them after popular handsets means chasing hardware that changes every year and missing every width in between, tablets most of all.
Anything that depends on hover. A tablet has the width to be handed the desktop layout and no pointer to operate it, so mega menus that open on hover become menus that do not open at all, or open and cannot be dismissed. The second casualty is local navigation, which often gets dropped at the mobile breakpoint and never restored at the tablet one. Both are decision failures rather than capability failures: the tablet inherited a composition instead of being designed one, and it is usually the width nobody reviewed.
Every destination becomes responsible for its own orientation. A reader landing mid-structure has seen none of the map, so the page has to answer five things by itself: what this is, where it sits, what is nearby, how to go up, and how to get out. Deep-link entry is a good thing — a QR code on a machine opening straight to that asset is excellent architecture — provided the page it lands on names the asset, the site, and the route to everything else. A page that only makes sense to someone who walked in through the homepage is a page most of your audience will never understand.
Five things, and all of them are architecture rather than sync: a stable address for the destination, the same name for it on both devices, preserved state, an obvious handoff, and a way back. Where names drift between devices — “Documents” on one, “Files” on the other — the person is not continuing a task, they are starting a second one and hoping it is the same. Continuity failures usually get logged as engineering bugs when they began as two teams naming the same node differently.
Usually because only one of them was designed and the other was derived. Treating mobile and desktop as two compositions of one structure — same content, same logic, different arrangement — makes the second one a piece of work rather than a consequence. The tell is in how success is claimed: if the mobile check is "we narrowed the window and it looked fine," no mobile composition exists yet. Desktop success is not evidence about mobile, and the review that only narrows a window is checking the desktop layout twice.
Every number quoted above, with where it comes from and why it is here.
Four things changed in how you approach a layout — and one place to take them next.
The device is settled. Now the words on the doors — the lowest-glamour, highest-leverage part of the whole discipline.