Consent prompt

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?