Consent, Interrupted: Designing UK Cookie Banners That Don’t Wreck the Page

There is a particular kind of disappointment that comes from opening a UK website on your phone and being greeted by a consent banner that covers half the screen. The page is there, somewhere. The thing you came for is behind a modal, a sticky footer or a full-width panel asking you to make a series of choices about partners you have never heard of. It is legal plumbing, and it is often terrible design.

None of this is an argument against consent. UK sites need to handle cookies and similar technologies properly under UK GDPR and the Privacy and Electronic Communications Regulations. The argument is simpler: consent interfaces are part of the page. They should be designed, specified, tested and maintained like any other component. Too often they are bolted on late, loaded by a third-party script and left to fight the layout.

The mobile viewport is not a suggestion

On a desktop screen, a consent banner can sit at the bottom and feel like a mild interruption. On a phone, it can be a different beast. A bottom sheet with a heading, three paragraphs, an accept button, a reject button and a manage preferences link can easily consume a third of the viewport. Add a sticky header and a browser toolbar and the actual page becomes a rumour.

The first impression matters. A visitor arriving from a search result wants to know whether they are in the right place. If the first thing they see is a wall of consent copy, the answer is harder to find. That is a design problem, even if the copy is legally sound.

Mobile design also has to account for safe areas, on-screen keyboards and thumb reach. A reject button that sits under the iOS home indicator is not a fair choice. A preferences panel that opens into a keyboard-covered text field is not a usable flow. These are ordinary interface concerns. Consent is not exempt from them.

Layout shift is a design bug, not a fact of life

One of the most common consent problems is late loading. The page renders, the text settles, you start reading, and then the consent script arrives and pushes everything down. That is cumulative layout shift, and it is exactly the kind of thing Core Web Vitals were designed to expose.

The fix is not glamorous. Reserve space for the banner before it loads. Render a static shell or placeholder with the same dimensions as the final component. Use CSS containment where it helps. Avoid injecting a full-width block into the document flow after the hero section has already rendered. If the consent interface is fixed or sticky, make sure it does not change the height of the underlying content when it appears.

Fonts and icons matter too. A consent banner that loads its own web font late can resize its buttons and shift its own layout. A preferences modal that pulls in an icon font after the first paint can jump. These are small details, but they are the same details designers sweat over elsewhere on the page. Consent should get the same attention.

Core Web Vitals don’t care about your legal team

Consent scripts are often heavy. They may load a tag manager, a consent management platform, several vendor scripts and a pile of analytics code. On a fast office connection this can feel invisible. On a congested mobile network in a UK town centre, it can delay interaction and make the page feel sticky.

Interaction to Next Paint is the metric to watch here. If the main thread is busy parsing consent logic and loading vendor tags, taps and clicks can feel delayed. The user does not know why. They just experience a page that seems reluctant to respond.

There is a balance to strike. Consent must be collected before non-essential scripts run, so you cannot simply defer everything into the distant future and hope for the best. But you can keep the consent layer lean, avoid unnecessary vendor bloat and make sure the interface becomes interactive quickly. A lightweight banner that works is better than a feature-rich one that stutters.

Dark patterns are a design smell

A consent flow can be technically compliant and still feel hostile. The classic pattern is asymmetry: a bright, prominent accept button and a muted, tiny reject link. Another is the preferences maze, where rejecting all requires more clicks than accepting all. Pre-ticked boxes, confusing toggles and vague legitimate interest language all push in the same direction.

These choices do not just irritate people. They erode trust. A visitor who has to fight the interface to say no is less likely to believe anything else the site says about privacy. That is a brand problem as much as a legal one.

Good consent design is not about being clever. It is about being clear. Accept and reject should be equally easy to find and equally easy to use. The copy should say what is happening in plain English. The preferences panel should be understandable without a glossary. If the flow needs a dark pattern to get the desired opt-in rate, the problem is the request, not the design.

Specify the consent flow like any other component

Designers can do a lot of useful work before the legal team signs off the copy. Start with the component spec. What is the maximum height on a 360px-wide viewport? Does it use a bottom sheet, a modal or an inline bar? What are the z-index rules? Does it lock scrolling? How does it behave when the keyboard is open? What happens on reduced motion settings?

Define the states. First visit, returning visit, accepted all, rejected all, custom preferences, consent expired. Each state needs a visual and interaction definition. Each state needs to be testable. A consent banner that only looks right on the first visit is not finished.

Accessibility belongs in the spec too. Focus should move into a modal and return to a sensible place when it closes. Buttons need clear labels. Colour contrast needs checking. The banner should not trap keyboard users in a loop with no escape. These are not exotic requirements. They are the basics of building an interface for real people.

Test it like a component, not a legal afterthought

Consent flows deserve a test matrix. Run them on a small phone, a large phone and a desktop browser. Throttle the network and watch what happens before the script loads. Check the layout shift in field data and in the lab. Click through every state with a keyboard. Try it with a screen reader. Test the reject path as carefully as the accept path.

Visual regression testing helps here, especially when the consent platform updates its own markup. A screenshot of the banner in its loading, open and closed states can catch a lot of quiet breakage. So can a simple rule: if the consent interface changes the position of the main content after first paint, treat it as a bug.

Compliant and well-designed should not be opposites. A consent flow can respect UK privacy law and still respect the person using the site. It can be short, clear, accessible and stable. It can be built into the page rather than dumped on top of it. The banner is not an interruption to the design. It is part of the design, and it should be held to the same standard.