Hanad KubatVisit Website →
← Back to blog

Data Consent UI: How to Design It So It Holds Up

October 25, 2026
Data Consent UI: How to Design It So It Holds Up

A data consent UI is the screen, banner or form where a person agrees to how you use their personal data. It is valid under GDPR only if the agreement is freely given, specific, informed and unambiguous, and you can prove it later. That is a design problem and an engineering problem at once: the layout has to be honest, and the system behind it has to record and respect every choice.

I am Hanad Kubat, a senior software engineer in Vienna. I build first versions of software products for founders and owner-operated businesses, and consent is one of the places where a quick build most often goes wrong. This guide covers what a consent interface must do, how to lay it out, what to log, and when you should not ask for consent at all.

Hanad Kubat
Build Consent Into Your Product
Hanad Kubat builds working software for founders and owner-operated businesses, with code designed to respect user choices.
Visit Hanad Kubat

Key takeaways

  • Consent is valid only if it is freely given, specific, informed and unambiguous, and given by a clear affirmative act. Pre-ticked boxes and silence do not count.
  • Withdrawing must be as easy as agreeing, and refusing must not cost the user core functionality. If it does, consent is probably the wrong legal basis.
  • Each purpose needs its own choice. One "Accept all" button with no granular controls is a compliance gap, however clean it looks.
  • The interface is half the work. A time-stamped consent log and code that actually respects the choices are the other half.
  • GDPR applies to people in the EU wherever your company sits, so a US startup with European users needs this too.

Table of Contents

The law does not prescribe a layout. It prescribes properties. The European Data Protection Board lists four elements of valid consent, and each one maps to a design decision.

ElementWhat it meansWhat it looks like in the UI
Freely givenNo pressure, no penalty for refusingReject sits next to Accept; the service still works if the user declines
SpecificOne choice per purposeSeparate toggles for analytics, marketing, personalization
InformedThe user knows what they agree to before actingYour identity, the purpose and the data categories are shown up front
UnambiguousA clear affirmative actThe user clicks or toggles; nothing is pre-selected

The text of the regulation is explicit that silence, pre-ticked boxes and inactivity are not consent. So a banner that says "by continuing to browse you accept" fails at the first hurdle.

Informed: say who, why and what before the click

Before the user acts, the screen should name the controller (your company), the purpose of the processing and the categories of data involved. Many founders push this into a privacy policy link and call it done. A link is fine for detail. The essentials belong on the screen where the decision happens, in plain words.

A weak line: "We use cookies to improve your experience." A better line: "Acme Ltd would like to measure which pages you visit, using an anonymous ID stored in your browser, to improve the product. You can say no and still use everything." It names who, what and why, and it states the consequence of refusing.

Freely given: no penalty, no bundling

The EDPB's 2026 summary says controllers must be able to show that withdrawing consent is as easy as giving it, and that refusing or withdrawing must not lead to detriment such as losing core service functionality or unexpected costs.

Two practical rules follow:

  1. Never gate the core product behind a marketing or analytics choice.
  2. Never bundle consent into terms of service. "I agree to the terms and to receive promotions" in one checkbox is two purposes in one click.

Layout rules that hold up

Regulators have been looking closely at the visual side of consent. A policy briefing on UX dark patterns in consent is one of many signs of that attention, and the common patterns are well known. Here is how I design around them.

Give refusal the same weight as acceptance

If "Accept" is a bright button on the first layer, "Reject" belongs on that same layer, same size, similar contrast. Hiding refusal behind a "Manage settings" link, a grey text link or three extra clicks makes the choice unequal. The test is simple: count the clicks to say yes and the clicks to say no. They should match.

Layer the information, do not bury it

A two-layer pattern works well. The first layer carries the short explanation and three actions: accept, reject, and customize. The second layer holds the purpose-by-purpose toggles and the detail. Users who just want to decide can do it in one click. Users who want control can find it.

Two-layer consent interface and its actions

Keep the screen a decision, not a puzzle

A consent screen is a page like any other: one decision, clearly framed, with an obvious next step. The same logic is behind the case for clearer next steps instead of more content. Skip the jokes, the guilt-trip copy ("No, I don't care about my experience") and the countdown timers. They push users toward a result and undermine the claim that the choice was free.

Defaults: everything off

Optional purposes start switched off. Strictly necessary processing, such as keeping a login session alive, does not need a toggle, but it should still be described. The user turns things on, never the other way round.

Purpose-by-purpose controls

The EDPB's guidance for small businesses stresses that consent must be specific to each purpose, which means granular options whenever you do more than one thing with the data.

A typical SaaS product has at least these purposes:

  • Strictly necessary (login, security, load balancing): no consent needed, explain only.
  • Product analytics: separate toggle.
  • Marketing email: separate toggle, ideally collected where the user signs up for it.
  • Advertising or retargeting pixels: separate toggle.
  • Sharing data with an AI provider for a feature: its own clearly worded choice if consent is your basis for it.

The hard part is not the toggle. It is what happens after. Your architecture has to respect the selections programmatically: if analytics is off, the analytics script must not load, not merely be hidden. I have seen consent screens that looked perfect while the page fired every tracker on first load. The fix is to gate each script and each server-side data flow on a stored consent state.

If you run paid campaigns, consent state also shapes what your advertising platforms can see, which is why privacy-first changes in ad platforms matter to the marketing side of this decision.

Under Article 7(1) of the GDPR, the controller must be able to demonstrate that the person consented. The UK regulator's guidance on this, written for UK GDPR but built on the same article, says you need an audit trail of how and when consent was given.

In practice, each consent event should store:

  1. A user or anonymous visitor identifier.
  2. The exact choice per purpose (granted or denied).
  3. A timestamp in UTC.
  4. The version of the consent text and the layout shown at that moment.
  5. The channel (web banner, signup form, in-app settings).
  6. Every later change, including withdrawal, as a new row. Do not overwrite.

The version field is the one founders skip. When your wording changes, old consents were given under old wording. If you cannot show which text a user saw, you cannot show what they agreed to.

Withdrawal: the flow that fails audits

The typical failure is asymmetry: one click to accept at signup, but withdrawal requires emailing support. Build a permanent entry point instead, such as a "Privacy settings" link in the footer and in the account page, that reopens the same controls with the current state shown. Changing a toggle should take effect immediately, write a new log row, and stop the related processing, including scripts and background jobs.

Also decide what withdrawal does to data already collected. Consent withdrawal does not make earlier processing unlawful, but you should stop further use and, where no other basis applies, delete the data. Write that rule down before you build the screen, because the UI copy depends on it.

Many founders assume consent is the catch-all for GDPR. It is often the hardest legal basis to maintain. Consent is one of six lawful bases under Article 6, and the EDPB's SME guide says you must identify the appropriate one because each comes with its own requirements.

A quick sanity check:

  • If the product cannot work without the data, such as an address for delivery, the basis is usually performance of a contract, not consent. Asking for consent there is misleading, because refusing would break the service.
  • If you have a narrow, documented interest that users would reasonably expect and that does little harm, legitimate interest may fit, with its own balancing test.
  • If the processing is optional and users could say no without losing anything, consent is the natural basis.

This choice is a legal judgment. Where you are unsure, ask a privacy lawyer or your data protection officer to confirm the basis before you design the screen, because the basis determines what the screen must offer. Minimizing the data you collect in the first place also shrinks the number of consents you need, which is the point of GDPR data minimization in an MVP.

Internal tools carry a trap. If an employee is asked to consent to monitoring by their employer, the EDPB's view is that it is almost never freely given because of the power imbalance. A consent checkbox in a staff time-tracking or location tool does not fix that. Use another basis, document it, and keep the data you collect to what the workflow needs.

Clinics, law firms, trades and logistics operators run into a related issue: customer data in a custom tool. Often the basis there is contract or legal obligation, and the interface should simply inform. If the tool also sends outreach, the same record-keeping thinking applies to audit-ready GDPR email records, where each send needs a defensible basis on file.

There are two honest routes.

Use an off-the-shelf consent management platform. For a marketing site with standard cookies, this is usually the right answer. Plans run from free tiers to roughly $8 to $19 per month per domain for the common paid ones, according to a 2026 G2 roundup. They handle the banner, the logging and the proof for audits. Do not spend thousands on custom code to do what a monthly subscription does.

Build custom consent handling. This makes sense when consent lives inside the product: per-feature AI consent, granular in-app preferences tied to user accounts, consent that has to flow into your own database and APIs. Even then, I would not rebuild the cookie banner. I would use a platform for the website and build only the in-app preference center and the consent log your product needs.

Build it, or buy a consent platform? — overview diagram

The mistake I see most in MVP builds is not a missing banner. It is an unreliable log, or a withdrawal path that is harder than the acceptance path. Those two are the cheapest to get right early and the most expensive to retrofit.

A short build checklist

  1. List every purpose for which you process personal data, and choose the legal basis for each.
  2. Mark which purposes need consent. Remove the rest from the consent screen.
  3. Write the first-layer copy: who you are, what you do with the data, what happens if the user says no.
  4. Design accept, reject and customize with equal weight.
  5. Default all optional purposes to off.
  6. Gate scripts and data flows on stored consent state.
  7. Store a versioned, time-stamped log of every choice and change.
  8. Add a permanent privacy settings entry point that mirrors the original controls.
  9. Test with a clean browser: with everything rejected, confirm nothing optional fires.
  10. Re-ask when the purposes or wording change materially.

If your product uses AI features that send user content to a model provider, add that flow to the list. My checklist for GDPR and AI covers the gaps that usually show up there, and the broader privacy by design approach for SaaS shows how to build these controls in rather than bolt them on.

My perspective

I treat consent as a feature with a spec, not a legal footnote. When a founder brings me a prototype built in a no-code or AI tool, the consent screen is usually a banner that looks right and does nothing: scripts load regardless, nothing is logged, and withdrawal does not exist. It passes a glance and fails a review.

My approach is deliberately boring. I decide the legal basis for each purpose first, because that removes half of the screens. Then I build the smallest interface that is honest: equal buttons, plain wording, granular toggles only where consent is truly the basis. Behind it goes a plain SQL table for the consent log and a single check that every optional script and data flow passes through. A developer who inherits it should understand it in an hour.

I also tell founders when not to build. If a hosted consent platform covers your marketing site, use it. I would rather you spend your budget on the workflow your users pay for.

— Hanad Kubat

If your prototype has a consent screen that does not actually control anything, or you need a first version with logins, payments and privacy controls that survive a review, I build this as fixed-price work. Builds start from €12,000, delivered in two to four weeks, with no agency overhead or project-manager layer, and you own the code from the first commit. See what I build on hanadkubat.com, or read how one engineer can fix GDPR for a SaaS product in weeks.

FAQ

Not always. Consent is only one of six lawful bases under GDPR. You may collect data without consent if another basis applies, such as performance of a contract or a legal obligation. If you rely on consent and do not have valid consent, the processing is unlawful.

The regulation describes consent as a freely given, specific, informed and unambiguous indication of the person's wishes, given by a statement or clear affirmative action. Recital 32 and Article 7 set this out. There is no mandatory script, so your own wording should name the controller, the purpose and the data in plain language.

For a website with standard cookies, usually yes, because a platform handles the banner and the logging cheaply. For consent inside a product, such as per-feature AI choices, you will likely need custom preference controls and your own consent log. Many products need both.

Generally no. If refusing means losing core functionality, the consent is not freely given in the EDPB's view. Use a different legal basis for what the service needs, and keep consent for optional extras.

Sources