Isolation has to hold at every breakpoint
Aliases: responsive isolation · collapsed adjacency · breakpoint leakage
What it is
On the desktop mockup, Delete lives inside More and Save is the primary, a whole toolbar apart. At phone width the toolbar collapses to a row of icons and Delete sits in the next slot to Save — isolation existed only on that desktop artboard. Isolation across breakpoints asks that the spatial relation between destructive and frequent still hold at every width, orientation and platform that will actually be used, not only on the main board of the file.
The failure is rarely in a design review. It is in the “small-screen pass” that flattens an overflow and squeezes secondary items back into the primary bar.
Why it happens
Responsive layout saves width by wrapping, hiding and merging. All three rewrite neighbourhoods: wrapping may pull what used to be the next row up beside the primary; hiding More often promotes the destructive item inside it back into the bar; merging packs different jobs into one overflow, then lists them in source order — and if that order is Save, Delete, they are adjacent again inside the list. Isolation is a constraint, not an arrangement that happened to appear at the main breakpoint. The constraint has to be written as an invariant of the layout at every breakpoint, or the wrap function will eat it as expendable gap.
Landscape, split-view and a foldable’s intermediate widths each trigger another neighbour recalculation.
Where it stops holding
A UI that only ever has one width (an industrial panel with hardware keys, a single-window installer) has no breakpoint to break. Print stylesheets and desktop widgets that are not interactive are out of scope. Server-rendered email HTML often cannot do fancy breakpoints; isolation then means the destructive link in its own block, not on the same line as the primary CTA. Platform toolbar components that refuse custom spacing may force the destructive item out of the component entirely, rather than a squeezed gap inside it.
Applying it
- Write “destructive shall not be a neighbour of frequent” as an acceptance condition across breakpoints. Capture the neighbour list at every width and orientation, not only on the main board.
- At narrow widths, prefer “destructive stays in the overflow” over “flatten the overflow”; flattening is how isolation is dismantled.
- Inside the overflow list, do not pack Save and Delete in source order either. Insert an unrelated item or a group heading between them.
- How to check: on device or emulator, walk every width the product claims to support (including split-view and foldable mid-states) and screenshot each frequent button’s neighbours. Any frame where the destructive control enters the next slot has not finished isolation at that breakpoint.