The dominant pattern in responsive design is to start with the desktop layout and shrink it. Columns become rows. Sidebars become drawers. Three panes become one. The mental model is that mobile is the same product, just narrower.
This works for content sites and most documentation. It fails for software that is operationally dense. A marketing platform has too many surfaces, too many controls, too many panels of context to compress into a single column without making the experience feel cramped or amputated.
A phone is not a smaller monitor. It is a fundamentally different way to enter the same content. I design accordingly.
The same content, a different door
The desktop product has a left sidebar, a centre conversation panel, and a right document panel. On a phone, none of those persistent surfaces fit. The user does not want them simultaneously. They want to focus on one at a time, and they want to switch between them with their thumb, not their cursor.
The mobile product has the same content but a different entrance. The conversation is the primary surface. The sidebar lives behind a small floating trigger that opens a sheet from the bottom. The document panel lives behind another trigger that opens a sheet from the side. Same content, different doors.
This is not a responsive breakpoint. It is a parallel structure. The components that render the bottom sheet are not the same components that render the desktop sidebar. They share the underlying data, the underlying state, the underlying actions. They do not share a layout.
When responsive is enough, and when it is not
Some surfaces respond well to simple breakpoints. A document, a stage view, an email composer. These are essentially long-form pages whose content scales naturally as the viewport shrinks. I use responsive breakpoints freely on these surfaces and they work.
Other surfaces do not respond well. Anything with multiple persistent panels. Anything with hover-triggered controls. Anything that depends on the user being able to see two different things at once. For these, I build a parallel mobile entrance with controls that respect the touch context.
The decision rule that fell out: if the desktop layout has more than one persistent panel, mobile gets a parallel structure. If it has one panel and an overflow menu, responsive breakpoints are enough.
What touch needs that mouse does not
Mouse interactions can be small. A four-by-four pixel close button is fine on desktop. The user has a precision pointing device. On a phone, the same target is a misery. Touch targets need to be at least forty-four pixels on a side. They need to be spaced. They cannot be hidden behind hover.
This sounds obvious. It is also routinely violated. Many products that claim to be mobile-friendly have desktop-sized hit targets that simply happen to render in a narrower column. The user can use the product on their phone, but it is hostile.
I design every touch target on the mobile entrance to be a minimum size, to be tap-friendly, and to never depend on hover. If a control requires hover to be visible on desktop, the mobile equivalent gets a different affordance. A long-press, a swipe, an explicit overflow menu. Same intent, different mechanism.
The honest cost
Building a parallel mobile entrance costs more than responsive breakpoints. You maintain two layouts that share data but not structure. You test more permutations. You think harder about which controls belong to which entrance.
The cost is the price of admission for being usable on a phone. The dominant alternative, which is to ship a single layout that technically renders at all viewports, produces software that is technically responsive and practically miserable on small screens.
Same content. Different door. Both designed for the context they live in.