| name | consent-and-preference-system |
| description | Design and implement a systematic framework for user privacy, managing consent banners, preference centers, and persistent privacy controls to balance legal compliance with user trust. |
Consent and Preference System
Purpose
The Consent and Preference System provides a methodology for designing the visual
and structural framework of user privacy management. It ensures that privacy
notices, cookie banners, and granular preference controls are integrated into
the website experience in a way that is legally compliant (GDPR, CCPA),
accessible, and high-trust. This system prevents "consent fatigue" by
organizing information into clear hierarchies and providing intuitive controls
for data sharing.
Use Cases
- Initial Consent Banners: Designing the first-touch overlay or bar that
notifies users of cookie usage.
- Granular Preference Centers: Creating modals or pages where users can
toggle specific data categories (Analytics, Marketing, etc.).
- Persistent Privacy Triggers: Implementing subtle "Privacy Settings"
triggers that remain accessible after the initial choice.
- Regulatory Adaptation: Standardizing the design to meet varying
requirements across different regions (e.g., "Reject All" button requirements).
- Communication Preferences: Designing the UI for managing newsletter or
marketing notification opt-ins.
When NOT to Use
- Internal Data Governance: This skill handles the UI/UX layer; it does not
manage the backend data architecture or legal policy writing.
- Generic Banners: For simple announcements like sales or maintenance, use
banner-and-alert-system.
- System Settings: For purely functional app settings (e.g., Theme,
Language) without privacy implications, use
site-navigation-system or
dedicated settings views.
Inputs
- Regulatory Requirements: Which laws apply (GDPR, CCPA/CPRA, DMA)?
- Data Categories: A list of all data-gathering tools (Necessary,
Functional, Analytics, Marketing/Targeting).
- Brand Voice: The intended tone for privacy communication (e.g.,
Transparent, Minimalist, Reassuring).
- Layout Context: Where the banner should sit (Bottom Bar, Floating Box,
Full-screen Modal).
- Browser Signals: Whether the site must detect and honor Global Privacy
Control (GPC) or "Do Not Track" signals as a valid opt-out.
Outputs
- Consent Anatomy Spec: Definition of the banner/modal regions (Heading,
Description, Toggles, Actions).
- State Matrix: Visual specs for Pending, Accepted, Rejected, and Focused
states.
- Preference Center Blueprint: A structural map for granular category
management.
- Interaction Spec: Rules for backdrop behavior, "Reject All" prominence,
and persistent trigger placement.
Workflow
1. Categorize the Consent Level
Determine the required level of interruption based on legal and UX goals:
- Level 1 (Implicit/Info): A subtle bar that doesn't block interaction.
Best for low-risk regions or non-tracking sites.
- Level 2 (Active/Modal): A floating box or modal that requires a choice
before or during navigation. Best for GDPR/CCPA compliance.
- Level 3 (Hard Gate): A full-screen overlay that prevents any access until
a choice is made. Only for extreme compliance or age-verification scenarios.
2. Choose the Spatial Pattern
- The Bottom Bar: Spans the full width at the bottom. Low interruption,
familiar pattern.
- The Floating Box: Usually bottom-left or bottom-right. Less obstructive
to main content but highly visible.
- The Preference Modal: A centered overlay for granular choices. Triggers
from a "Manage Preferences" button.
3. Establish Information Hierarchy
Avoid "Wall of Legalese" fatigue:
- Heading: Clear and honest (e.g., "Your Privacy Choices").
- Primary Description: 1-2 punchy sentences explaining why data is
collected and the user's rights.
- Category Labels: High-level buckets (e.g., "Personalization,"
"Advertising") with expandable "Learn More" details.
4. Design the Action Priority
Follow "Equal Prominence" rules where required:
- Primary Actions: "Accept All" and "Reject All" (or "Confirm Choices") should
ideally have similar visual weight to avoid "Dark Patterns."
- Secondary Action: "Manage Preferences" or "Cookie Settings" link to the
granular view.
- The Escape Hatch: Ensure users can easily find the "Close" or "Dismiss"
if implicit consent is used.
5. Define the Persistent Trigger
Consent is a dynamic state; users must be able to change their mind:
- The "Privacy Shield" Icon: A small, persistent floating icon (usually
bottom-left) that re-opens the preference center.
- Footer Link: A dedicated "Cookie Settings" link in the
site-footer-system.
6. Respect Browser-Level Opt-Out Signals
For jurisdictions that recognize automated opt-out mechanisms (e.g., CCPA/CPRA
recognition of Global Privacy Control):
- Detect and Apply: If a GPC signal is present, treat it as a valid
"Reject" or "opt-out of sale/sharing" signal and reflect that state in the
preference center without requiring the user to re-toggle it manually.
- No Re-Prompting: Do not re-show the initial banner solely to ask the user
to override a GPC signal they already sent.
- Transparency: Surface the detected signal in the preference center (e.g.,
"We detected a Global Privacy Control signal and have applied your
opt-out") so the state is not silently applied.
Decision Rules
- The "Equal Weight" Rule: If your region requires "Reject All" (like the EU),
the button must be as easy to find and click as "Accept All." Avoid making
the "Reject" button a tiny text link while "Accept" is a large blue button.
- The "No Pre-checked" Rule: All non-essential (Analytics, Marketing)
toggles must be OFF by default for GDPR compliance.
- The "Clear Language" Rule: Avoid technical jargon. Use "Improve our site"
instead of "Process pixel-based telemetry."
- Layered Disclosure: Keep the initial banner simple. Move the 20-paragraph
policy list into the Preference Center or a dedicated Privacy Policy page.
- The "Honor the Signal" Rule: A detected GPC opt-out takes precedence over
a stale local "accept all" cookie; do not let a cached consent record
override a fresh browser-level opt-out signal.
Constraints
- Accessibility: Banners must be reachable via keyboard. Preference modals
must trap focus, and the focus indicator must remain visible and unobscured
while trapped (WCAG 2.2 SC 2.4.11). All toggles must have clear ARIA labels
and meet the 24x24px minimum target size (SC 2.5.8).
- Contrast: Button text and toggles must meet WCAG AA (4.5:1) contrast.
- Responsiveness: Banners must never overlap primary mobile navigation
(like a bottom nav bar). Switch to a full-screen drawer if a floating box is
too cramped.
Common Failure Patterns
- The "Dark Pattern" Trap: Making it impossible to find the "Reject" button
to force user consent.
- Interference with Nav: Placing a bottom banner that covers the site's
mobile menu or primary CTA.
- Z-Index Wars: The banner appearing under other overlays or menus,
rendering it unclickable.
- The "Checklist of 50": Forcing users to toggle 50 individual vendors
rather than high-level categories.
- Broken Escape: Not allowing users to change their preferences once the
banner is closed.
Validation Criteria
