Here is the uncomfortable truth about most cookie banners: they were designed by lawyers, not designers. You can tell. They sit there like a passive-aggressive sticky note, blocking your content, hiding the reject button in a font size that would strain the eyes of someone half my age, and generally making a first impression that screams “we don’t actually want you to say no.” That is not just aesthetically grim, it is increasingly illegal. The ICO’s 2024 enforcement push against non-compliant consent mechanisms made clear that cookie consent UI design UK ICO PECR compliance is not a technicality you can paper over with a barely-visible opt-out link.
This piece goes through what PECR actually demands, what the ICO’s published guidance says about interface design specifically, and how to build a consent flow that is both genuinely compliant and not a conversion catastrophe. Because those two things are not mutually exclusive, they just require some actual design thinking.
What PECR actually requires (without the legalese)
The Privacy and Electronic Communications Regulations 2003, PECR, sit alongside the UK GDPR and are enforced by the ICO. For cookies specifically, PECR requires prior, informed, freely given consent before any non-strictly-necessary cookie is set. That is the short version. The full version has some sharp teeth.
“Freely given” is where most implementations fail. If you pre-tick boxes, if accepting is one click but rejecting requires three, if you grey out the reject button or bury it in a “Manage preferences” submenu that takes six taps to navigate, that is not freely given consent. The ICO has been explicit: consent obtained through designs that nudge users towards acceptance does not meet the standard. They call these dark patterns, and they have published specific examples of what counts as one.
Strictly necessary cookies, those needed to make the site function, like session cookies, do not need consent at all. Everything else does. Analytics, advertising pixels, A/B testing scripts, heat-mapping tools, embedded YouTube players: all of these require prior opt-in unless you are routing them through a proxy that strips identifiers. That last option is genuinely worth exploring if analytics are your only concern, but it is out of scope here.
The dark patterns the ICO specifically flags
I would recommend reading the ICO’s updated cookie guidance directly, because it is more specific than most designers expect. The patterns they name include:
Asymmetric prominence. The “accept all” button is large, colourful, and high-contrast. The “reject” or “manage” option is smaller, greyed out, or styled as a text link. This visual hierarchy communicates a preference, which means consent is not freely given.
Forced interaction. Making users click through multiple screens to reject, whilst acceptance is one button. If it takes three steps to say no and one step to say yes, you have built a funnel, not a consent flow.
Confusing language. “Allow partners to use personalised data” is not informed consent. People need to understand what they are agreeing to. Plain English is not optional.
Consent walls. Blocking content access unless the user accepts all cookies. The ICO’s position is that this can undermine the “freely given” requirement, particularly where genuine alternatives to the service do not exist.
UI patterns that work without being ugly
The good news is that compliant does not mean clunky. Here is how I would build this.
Symmetric button styling
Give “Accept all” and “Reject all” equal visual weight. Same button size, same border treatment, same font weight. The only permissible difference is colour, and even then, use brand colours rather than a bright green accept versus a faded grey reject. Monochrome button pairs work particularly well: both buttons outlined, no fill, identical typography. Clean, considered, legally sound.
Three-option layouts
The most practical pattern for most UK product teams is a three-button row: “Reject all”, “Manage preferences”, “Accept all”. This gives users the quick binary choice if they want it, whilst making granular control available without friction. Put “Reject all” on the left, counterintuitive, but it signals confidence rather than reluctance. Users who are privacy-conscious will find it immediately; users who genuinely want to accept everything will still accept.
The modal vs banner question
Banners (bottom or top strips) tend to generate higher interaction rates but lower comprehension. Modals with a backdrop generate better-informed choices but disrupt flow more severely. For most sites, a centre-screen modal on first visit is the right call, it signals that the choice matters without being dismissive. Avoid full-screen takeovers; they are aggressive and associate your brand with the very dark patterns you are trying to avoid.
Preference panels worth building
The preference panel (reached via “Manage preferences”) is where most implementations fall apart. I have seen panels that list seventeen toggle switches with descriptions like “Audience measurement partner 4”, completely useless to an ordinary person. Build category-level toggles: Analytics, Marketing, Personalisation. Describe each in one sentence of plain English. Show which third parties are involved, but summarise rather than enumerate. Make the panel closeable without forcing a decision, some users just want to read before choosing.
If you are building this in a component library, the preference panel is a good candidate for a compound component pattern: a top-level ConsentPanel that takes category configs as props, renders toggle groups with associated descriptions, and emits a structured consent object that your tag manager or consent management platform can consume. Keep the state management simple, a flat object keyed by category slug is all you need.
Colour, contrast and accessibility
This connects to accessibility work more broadly. If you have been following guidance on designing for older users and accessibility for the over-55 audience, most of it applies directly here. Consent flows need to meet WCAG 2.2 AA contrast ratios; the ICO’s own published guidance references accessibility standards. Minimum 4.5:1 for body text, 3:1 for large text. Focus states on all interactive elements. No relying on colour alone to distinguish accept from reject.
Typography matters here too. Do not use a font size below 14px in a consent banner. Sixteen is more defensible. If you have been thinking carefully about your typography stack and system fonts, a consent modal is a good place to use a system font stack, it loads instantly, which matters given that consent must be presented before non-essential scripts fire.
Technical implementation notes
A few things I see trip up developers who are building consent flows from scratch rather than using a consent management platform (CMP).
First, no cookies should be set before consent is given. This sounds obvious but is violated constantly. If your analytics script fires on page load regardless of consent state, you are non-compliant before the banner has even rendered. Consent must gate script execution, not just set a preference that is read later.
Second, consent must be recorded and reproducible. You need to store what the user consented to, when, and which version of your policy was active at the time. A UUID per consent event, stored server-side, is the clean solution. Storing consent state only in a cookie is weakly circular and difficult to audit.
Third, consent must be withdrawable as easily as it was given. If your site has a footer link labelled “Cookie settings” that opens your preference panel, which was the mechanism for giving consent, that satisfies this requirement neatly. Make sure it actually works, and make sure it re-presents the panel with the current state rather than defaulting to all-off.
If you are building empty states into your consent flow (think: the preference panel before any categories have been toggled), there is a nice pattern for communicating status clearly covered in the piece on designing effective empty states for UK SaaS onboarding, the principle of communicating what will happen next applies well here.
Does any of this actually hurt conversion?
The honest answer is: a well-designed compliant consent flow will reduce your analytics data compared to a dark-pattern banner that coerces acceptance. That data was always unreliable anyway, because coerced consent produces noise rather than signal, people who clicked accept reflexively are not the engaged users your analytics should be modelling.
What it will not do is hurt your conversion rate in the sales funnel sense, provided the consent flow does not block content access. A modal that appears, presents a genuine choice, and dismisses cleanly adds perhaps two seconds to a user’s first visit. That is negligible against the reputational and legal cost of an ICO enforcement notice, which can run to fines of up to £500,000 under PECR, or higher under the UK GDPR framework that sits alongside it.
Build the consent flow as a real UI component, not an afterthought. Treat it with the same design rigour you would give a checkout flow or an onboarding sequence. That is the entire argument.
Frequently Asked Questions
What does PECR require for cookie consent in the UK?
PECR requires that you obtain prior, informed, and freely given consent before setting any non-strictly-necessary cookies. This means no pre-ticked boxes, no dark patterns that push users towards acceptance, and the ability to withdraw consent as easily as it was given. Strictly necessary cookies, session management, shopping baskets, are exempt.
Is a cookie banner enough to be ICO-compliant, or do I need a full consent management platform?
A banner alone is not sufficient; what matters is that non-essential scripts are genuinely blocked until consent is given, that preferences are recorded with a timestamp, and that users can change their choice later. A consent management platform (CMP) handles most of this, but you can build a compliant system from scratch if you implement the technical requirements correctly. The ICO does not mandate any specific tooling.
Are dark patterns in cookie consent actually enforced in the UK?
Yes. The ICO issued enforcement notices against major UK publishers in 2024 specifically citing non-compliant consent interfaces, including asymmetric button styling and buried reject options. Fines under PECR can reach £500,000, and the ICO has stated publicly that enforcement in this area is ongoing.
Can I style my accept button differently from the reject button?
Using different colours is acceptable provided there is no significant difference in prominence, size, font weight, and placement should be equal. The ICO’s guidance specifically flags making the reject option visually subordinate as a dark pattern. Monochrome, equal-weight button pairs are the safest approach.
Does a cookie consent modal affect page load performance or Core Web Vitals?
It can, but the impact is manageable. Using a system font stack in your consent modal avoids any additional font-loading overhead. The modal itself should be lightweight HTML and CSS, ideally inlined, so it renders before external scripts fire. Blocking non-essential third-party scripts until consent is given can actually improve your initial load performance, as those scripts are often the heaviest assets on the page.