UX Patterns Guide
UI + UX Trust, Safety, And Privacy standard

Consent prompt

Provide a consent prompt that is specific, informed, freely chosen, affirmative, granular where needed, easy to decline, easy to withdraw, and connected to a durable consent record that matches the visible choice.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The product needs a user's active agreement for optional data use, marketing, research participation, personalization, partner sharing, AI training, or sensitive-data processing.
  • The product can honor refusal, record the consent purpose, and provide a withdrawal route.

Avoid when

  • The choice is only about non-essential cookies or device storage; use cookie banner.
  • The user is granting device resource access through the operating system; use permission request.
  • The user is accepting terms, a contract, or a legal declaration; use legal acceptance.
  • The user is approving a one-time action before execution; use human approval gate.
  • The product cannot prevent optional processing before the user chooses or cannot honor withdrawal.

Problem it prevents

Users are often asked to agree to optional data use, marketing, research, AI training, personalization, or sharing at moments where the purpose, data, consequences, and withdrawal route are unclear, making the recorded agreement weak and the experience untrustworthy.

Pattern anatomy

What a strong implementation has to make clear

User need

The prompt may appear during onboarding, checkout, account creation, product settings, research signup, AI feature activation, beta enrollment, marketing signup, partner integration, or sensitive-data workflow.

Pattern promise

Provide a consent prompt that is specific, informed, freely chosen, affirmative, granular where needed, easy to decline, easy to withdraw, and connected to a durable consent record that matches the visible choice.

Required state

Pre-consent state with optional processing off and the core task still understandable.

Recovery path

The product claims consent because the user continued, closed the prompt, or failed to opt out.

Access contract

Use a labelled region or dialog title that names the consent purpose, not a vague privacy heading.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A research signup screen asks whether the user consents to being contacted for follow-up interviews, names the research team, shows what contact data is used, offers Yes and No thanks buttons, and links to withdrawal.
  • An AI writing tool asks whether the user wants workspace snippets used to improve future suggestions, shows included data types, keeps the default off, and records the consent version after opt-in.
  • A user declines partner sharing and can still complete checkout; the service records no partner-sharing consent and shows how to change the choice later.
  • A user consents to a beta research study, sees what data will be reviewed, receives a saved confirmation, and later withdraws from the account privacy page with the same purpose label.
Weak implementation

Vague, hidden, hard to recover from

  • A modal says By continuing you agree to personalized offers and partner sharing, with a large Continue button and a small privacy policy link.
  • A form checkbox is preselected for marketing, research, and product analytics together, with no separate decline or withdrawal route.
  • A user clicks Next to finish onboarding and unknowingly opts into marketing because the consent copy was bundled into the terms paragraph.
  • A user accepts a vague improve our service prompt, then discovers their messages were used for AI training and cannot find where to revoke consent.
UI guidance
  • Render a consent prompt as a focused opt-in decision that names the requester, purpose, data involved, optionality, benefit, consequence of declining, withdrawal route, and consent record before the user chooses.
  • Use equal-level accept and decline controls, granular purpose choices when purposes differ, clear affirmative action for opt-in, and a confirmation state that records purpose, version, timestamp, and withdrawal path.
UX guidance
  • Use consent prompt when the product needs the user to knowingly agree to a specific optional data-processing purpose such as marketing, research participation, AI training, personalization, partner sharing, or sensitive-data use.
  • Ask at a moment when the user understands the task and value, keep the service usable when consent is declined where possible, and make withdrawal as visible and easy as the original opt-in.
Implementation contract

What the implementation must handle

States

  • Pre-consent state with optional processing off and the core task still understandable.
  • Specific purpose state naming the requester, data, purpose, benefit, and optionality.
  • Accept consent state with clear affirmative action and saved consent record.
  • Decline consent state that keeps eligible core workflow available and records refusal without penalty.

Interaction

  • The prompt appears before optional processing begins and states exactly what agreeing enables.
  • Accept requires a deliberate action such as pressing a labelled button, checking an unchecked statement, or selecting an opt-in setting.
  • Decline is reachable at the same decision level and does not look disabled, hidden, or punitive.
  • Independent purposes are not bundled into one broad agreement unless they are truly inseparable.

Accessibility

  • Use a labelled region or dialog title that names the consent purpose, not a vague privacy heading.
  • Do not rely on color, size, contrast, or button order to steer users toward accepting.
  • Associate every checkbox or toggle with a complete purpose label and consequence description.
  • Announce saved, declined, withdrawn, expired, and renewed states without moving focus unexpectedly.

Review

  • What specific data use is the user agreeing to, and is it optional?
  • Can the user decline with comparable effort and continue the eligible core task?
  • Are separate purposes split into separate choices?
  • Does the prompt name the requester, data type, purpose, consequence, and withdrawal route?
Interactive lab

Inspect the states before you copy the pattern

Move a consent prompt through pre-consent, specific purpose, accept consent, decline consent, granular consent, explicit consent, confirmation, withdrawal, renewal, expired consent, permission-limited, and mobile compact states; compare with continue-to-agree, preselected, bundled-purpose, hidden-decline, processed-before-consent, no-withdrawal, and record-only failures.

Consent prompt
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Pre-consent state with optional processing off and the core task still understandable.

Keyboard / Access

Tab reaches purpose details, accept, decline, granular purpose controls, policy links, and withdrawal controls in a logical order.

Avoid Generating

Treating continued use, scrolling, closing, or inactivity as consent.
Evidence trail

Source-backed claims behind this guidance

ICO: What is valid consent?

Information Commissioner's Office - checked

Supports freely given, specific, informed, unambiguous consent, clear affirmative action, genuine choice, granular purposes, clear language, no pre-ticked boxes, and no inactivity-based consent.

EDPB: Consent under GDPR summary

European Data Protection Board - checked

Supports granular consent, clear affirmative action, no silence or pre-ticked boxes, and withdrawal as easy as giving consent.

Android Developers: Request runtime permissions

Android Developers - checked

Supports tying sensitive access requests to user actions, explaining private-data access, and handling grant or deny outcomes when consent prompts lead into platform permission requests.

Full agent/debug reference

Problem Context

  • The prompt may appear during onboarding, checkout, account creation, product settings, research signup, AI feature activation, beta enrollment, marketing signup, partner integration, or sensitive-data workflow.
  • The requester may need evidence of who asked, what purpose was presented, what data was named, what version of copy was shown, what the user chose, and whether the user later withdrew.
  • Consent may be optional while the core task continues, or it may be necessary for a separate optional feature that stays unavailable after refusal.
  • The prompt must not rely on silence, inactivity, preselected choices, hidden refusal, bundled terms, confusing double negatives, or consent collected after processing has already started.

Selection Rules

  • Choose consent prompt when the user must actively opt in to a specific optional data use, communication, study, sharing arrangement, personalization feature, AI training use, or sensitive-data processing purpose.
  • Use cookie banner when the choice is specifically about non-essential cookies, pixels, local storage, advertising tags, analytics tags, or similar device storage.
  • Use preference center when users are reviewing or changing multiple account preferences after the initial consent moment.
  • Use notification preferences when users are choosing message channels, topics, frequency, or subscription state rather than consenting to a separate data-processing purpose.
  • Use permission sharing when the decision grants another user, guest, team, or link access to an object.
  • Use human approval gate when the user approves or rejects a proposed action before execution rather than consenting to ongoing optional processing.
  • Use legal acceptance when the task is accepting terms or a contract; do not hide optional consent inside legal acceptance copy.
  • Ask close to the feature or data use so the user understands why the choice appears, but before optional processing begins.
  • Offer separate granular consent controls for separate purposes such as marketing, research, personalization, partner sharing, and AI training.
  • Refresh consent when purpose, data type, requester, partner, retention period, or consequence changes beyond what the user originally agreed to.

Required States

  • Pre-consent state with optional processing off and the core task still understandable.
  • Specific purpose state naming the requester, data, purpose, benefit, and optionality.
  • Accept consent state with clear affirmative action and saved consent record.
  • Decline consent state that keeps eligible core workflow available and records refusal without penalty.
  • Granular consent state for multiple independent purposes.
  • Explicit consent state for high-sensitivity use requiring a clear statement or checkbox next to the statement.
  • Confirmation state showing the saved purpose, version, timestamp, and withdrawal route.
  • Withdrawal state where users can revoke consent as easily as they gave it.
  • Renewal state when purpose, data, requester, or copy version changes.
  • Expired or stale consent state where optional processing stops until renewed.
  • Permission-limited or under-age state where the user cannot provide consent directly.
  • Mobile compact state where purpose, choices, and withdrawal route remain visible.

Interaction Contract

  • The prompt appears before optional processing begins and states exactly what agreeing enables.
  • Accept requires a deliberate action such as pressing a labelled button, checking an unchecked statement, or selecting an opt-in setting.
  • Decline is reachable at the same decision level and does not look disabled, hidden, or punitive.
  • Independent purposes are not bundled into one broad agreement unless they are truly inseparable.
  • The prompt explains whether the core task continues after refusal and what optional feature remains unavailable.
  • Saving a choice updates the runtime state and writes a consent record containing purpose, copy version, requester, timestamp, data type, and withdrawal state.
  • Withdrawing consent stops future processing based on that consent and leaves a clear record of the withdrawal.
  • Keyboard and screen-reader users can read the purpose, compare choices, make or decline a choice, and later find withdrawal controls without losing task context.

Implementation Checklist

  • Identify the requester, controller or product area, data type, processing purpose, retention expectation, and whether consent is the correct basis for the decision.
  • Write prompt copy in plain language that names the user benefit and the organizational use without vague phrases such as improve your experience.
  • Keep optional processing off by default and do not preload the data use before the prompt is answered.
  • Provide accept and decline actions with comparable prominence and effort.
  • Split independent purposes into granular choices and keep every optional choice off until selected.
  • Record purpose, requester, copy version, data type, timestamp, user, action, source surface, and withdrawal state.
  • Provide a stable withdrawal route and test that withdrawal changes the same runtime and record used by the prompt.
  • Test first ask, decline, accept, granular save, explicit consent, renewal, withdrawal, mobile layout, keyboard order, screen-reader naming, and evidence export.

Common Generated-UI Mistakes

  • Treating continued use, scrolling, closing, or inactivity as consent.
  • Using preselected checkboxes for optional processing.
  • Bundling marketing, research, partner sharing, personalization, and AI training into one broad choice.
  • Hiding decline behind a settings link or making refusal look unsafe.
  • Starting optional processing before the consent prompt is answered.
  • Using a privacy-policy link as the only explanation of purpose.
  • Recording only a boolean value without purpose, version, requester, or withdrawal state.
  • Making withdrawal harder than giving consent.

Critique Questions

  • What specific data use is the user agreeing to, and is it optional?
  • Can the user decline with comparable effort and continue the eligible core task?
  • Are separate purposes split into separate choices?
  • Does the prompt name the requester, data type, purpose, consequence, and withdrawal route?
  • Is optional processing blocked until affirmative consent exists?
  • What evidence proves which prompt version the user saw and what they chose?
  • Can the user withdraw consent later from a stable route, and does withdrawal change runtime behavior?
Accessibility
  • Use a labelled region or dialog title that names the consent purpose, not a vague privacy heading.
  • Do not rely on color, size, contrast, or button order to steer users toward accepting.
  • Associate every checkbox or toggle with a complete purpose label and consequence description.
  • Announce saved, declined, withdrawn, expired, and renewed states without moving focus unexpectedly.
  • Keep long purpose names, requester names, and withdrawal links wrapped on mobile without horizontal scrolling.
  • If a modal dialog is used, trap focus only while the dialog is open and return focus to the triggering task after the choice.
Keyboard Behavior
  • Tab reaches purpose details, accept, decline, granular purpose controls, policy links, and withdrawal controls in a logical order.
  • Enter or Space activates accept, decline, save, withdraw, renew, and close controls according to native button and checkbox semantics.
  • Escape closes only non-required explanatory panels; it must not silently accept or decline consent.
  • After saving or declining, focus moves to a confirmation or the next task step with the choice announced.
  • Withdrawal from settings returns focus to the relevant consent record after the state changes.
Variants
  • Marketing opt-in consent
  • Research participation consent
  • AI training consent
  • Partner sharing consent
  • Personalization consent
  • Sensitive-data processing consent
  • Explicit consent statement
  • Consent renewal prompt
  • Consent withdrawal prompt
  • Granular purpose consent

Verification

Last verified: