Why US Onboarding Patterns Break UK GDPR (and How to Fix Them)
So you’ve built a product that’s doing well in the US, and now you want to open it up to users in the UK. Great move. The UK is one of the largest software markets in the world, and demand for well-designed products is strong. Before you flip the switch, there’s one part of your product worth a close look: your onboarding flow.
Signup is where your product asks people for consent, tells them how you’ll use their data, and collects that data. UK GDPR has specific rules about how all of that has to work, and a lot of the patterns that are completely normal in the US will put you out of compliance the moment a UK user creates an account. That carries real legal exposure, and it costs you signups when people hit a consent screen that feels off.
The good news is that every one of these issues lives in your design, which means every one of them is fixable. Here are the six patterns we see trip up US products most often, why each one runs into UK GDPR, and how to fix it.
GDPR compliance in plain terms
A quick map of who and what you’re dealing with. The UK retained GDPR after Brexit as UK GDPR, sitting alongside the Data Protection Act 2018. The Privacy and Electronic Communications Regulations (PECR) cover cookies and electronic marketing. The Information Commissioner’s Office (ICO) enforces all of it, and its guidance is specific about what valid consent looks like: freely given, specific, informed, and unambiguous, and shown through a clear affirmative action. The UK also has a newer law, the Data (Use and Access) Act, that adds some differences from EU GDPR, so being compliant in the EU doesn’t automatically cover you in the UK.
That’s the standard your onboarding needs to meet. Now the patterns.
Pattern 1: The pre-checked box and the bundled agreement
The US pattern: one checkbox reading “I agree to the Terms of Service, Privacy Policy, and to receive product updates and offers.” Sometimes the box is already ticked.
Why it fails: UK GDPR is explicit that pre-ticked boxes do not count as consent, and bundling marketing consent with your terms means the consent isn’t freely given. A user who has to accept marketing in order to use the product was never given a real choice.
The fix: separate the two. Accepting your terms is part of forming the contract and doesn’t need a checkbox at all. Marketing consent gets its own unticked box, written in plain language, that a user can skip and still finish signing up. Keep a record of what each person consented to and when, since you may need to show it later.
Pattern 2: Opt-out marketing by default
The US pattern: everyone who signs up lands on the email list, with an unsubscribe link doing the compliance work.
Why it fails: PECR requires prior consent for email and SMS marketing. There’s a narrow exception known as the soft opt-in, which covers existing customers being contacted about similar products, but it only applies if the person was given a clear chance to refuse at the point their details were collected, and in every message after. Most US signup flows don’t meet those conditions, which turns the entire email program into a PECR violation.
The fix: design for the soft opt-in deliberately or use genuine opt-in. If you rely on the soft opt-in, the refusal option has to appear at collection, in the flow itself. Either way, the unsubscribe path should be one click, and preference changes should take effect immediately.
Pattern 3: The single-button cookie banner
The US pattern: a banner with a prominent “Accept All” and, somewhere in smaller text, a “Manage Preferences” link leading to a settings maze. Analytics and advertising cookies often fire before the user chooses anything.
Why it fails: PECR requires consent before non-essential cookies are set, and ICO guidance expects rejecting cookies to be as easy as accepting them. A banner where “Accept” is a button and “Reject” is confusing fails that test. Cookies firing pre-consent fail it even faster, and the ICO has been actively writing to companies about exactly this.
The fix: give “Reject All” the same visual weight as “Accept All,” hold every non-essential cookie until consent arrives, and offer granular categories for the users who want them. Your analytics opt-in rates will drop some, and that tradeoff is worth it against the compliance risk of getting this wrong.
Pattern 4: Collecting everything at signup
The US pattern: name, work email, phone number, company size, job title, and industry, all before the user has seen the product once. Sales wants the enrichment data.
Why it fails: UK GDPR’s data minimisation principle says you should collect only what you actually need for the purpose you’ve stated. A phone number isn’t necessary to create an account, so gathering it up front is hard to justify. Every extra field also adds to what you have to explain, since users have to be told why each piece of data is being collected.
The fix: progressive profiling. Collect the minimum at signup, then ask for more when it’s actually useful, with a short note on why. This is better conversion design too, so it’s an easy call. Shorter forms complete more often in every market.
Pattern 5: Privacy information hidden behind a link
The US pattern: a single “Privacy Policy” hyperlink at the bottom of the form, pointing to 6,000 words of legal prose.
Why it fails: Article 13 of UK GDPR requires that privacy information be provided at the point where you collect the data, and the ICO’s guidance favors layered, just-in-time notices over a wall of text nobody reads. A single link at the bottom of the page technically discloses the information while practically hiding it, and that gap is exactly what the guidance is built to close.
The fix: short contextual notices where data is collected. Next to the email field: “We use your email to sign you in and send account notices.” Next to the optional marketing box: what they’ll receive and how often. Link to the full layered notice for detail. This is microcopy work, and it’s some of the highest-leverage microcopy a product team can write.
Pattern 6: Consent that's easy to give and hard to take back
The US pattern: signup takes thirty seconds, while unsubscribing requires logging in, finding settings, and clicking through a guilt-trip screen. Account deletion requires emailing support.
Why it fails: UK GDPR states that withdrawing consent has to be as easy as giving it. Confirmshaming, buried controls, and friction-heavy retention flows fall under what the ICO and the Competition and Markets Authority have jointly called harmful online choice architecture, and it draws regulatory attention.
The fix: a preference center reachable in one click from any email, immediate effect on changes, and a self-serve account deletion path. If your retention flow needs dark patterns to work, the retention problem is upstream of the design.
One more: say where the data goes
If you’re a US company, your UK users’ data is probably crossing the Atlantic to your servers. UK GDPR allows that as long as you have the right safeguards in place, like the UK’s International Data Transfer Agreement or the UK Addendum to standard contractual clauses, and as long as you disclose the transfer in your privacy notice. Saying nothing about where the data goes is one of the most common gaps we see, and one of the easiest to close.
A self-audit checklist
- Are terms acceptance and marketing consent fully separated, with no pre-ticked boxes?
- Does your cookie banner offer “Reject All” with equal prominence, and do non-essential cookies wait for consent?
- Can a user complete signup providing only the data the account genuinely requires?
- Is privacy information visible at the point of collection, not just linked?
- Can users withdraw consent and delete their account as easily as they signed up?
- Does your privacy notice disclose international transfers and the safeguards behind them?
If you can’t answer yes to most of these, your onboarding flow has compliance gaps worth closing before you open the doors to UK users.
GDPR compliance is also good design
Here’s the part we love about this work. Every fix on this list makes your product better, not just more compliant. Clear consent, honest cookie choices, short forms, plain-language privacy notes, easy ways to opt out: these are the things that make people trust a product enough to keep using it. Meeting UK GDPR ends up being the same work as designing an onboarding flow that respects the people going through it.
At LunarLab, we help product teams design onboarding, consent, and privacy flows that meet UK GDPR and still convert well. If you’re getting ready to bring your product to the UK, or you want a second set of eyes on a flow you’ve already built, we’d love to help. Contact us for a free consultation.