Designing special category and sensitive personal data consent UI in Figma: explicit consent, layered notices, and withdrawal

Quick answer

Special category and sensitive data consent UI requires separate, explicit opt-in before collecting health, biometric, racial origin, union membership, or similar data—and clear withdrawal that stops downstream use. Design purpose-specific consent cards (never bundled with Terms), unchecked by default, with layered notices and an admin consent proof ledger. Start from the Figma guides hub and pair with biometric consent, consent admin, consent withdrawal, children’s privacy, and Dev Mode handoff.

---

Who this is for

• Product designers adding health questionnaires, diversity surveys, biometric login, or wellness features that touch GDPR Article 9 categories.
• Privacy and legal teams separating explicit consent from contract or legitimate-interest bases.
• Engineering teams gating APIs and storage until consent records exist with versioned policy text.

---

Sensitive data consent hub (admin overview)

SensitiveConsentHub — Acme App · 6 active purposes · 2.1% users opted in · 0 critical gaps
├── Header: Missing proof 0 · Withdrawal backlog 4 · Policy v4.2 live since 2026-07-01
├── Actions: [ New sensitive purpose ] [ Consent audit ] [ Withdrawal queue ] [ Policy publish ]
├── Tabs: Purposes · User ledger · Policies · Collection surfaces · Withdrawals · Blocks
├── Alert: Feature "Wellness pulse" · Collects health · 12 users without Art. 9 proof · 🔒 Blocked
├── Filters: Category (health|biometric|genetic|…) · Region · Status · Surface
└── Link: [Consent admin](/designing-consent-records-and-preference-management-admin-ui-in-figma/) · [ROPA](/designing-records-of-processing-activities-and-data-mapping-ui-in-figma/) · [Launch gates](/designing-privacy-by-design-launch-gates-and-feature-privacy-review-ui-in-figma/)

Section	Purpose
Purposes	Each Art. 9 processing activity with allowed categories
User ledger	Immutable consent records with policy version + IP/time
Policies	Layered notice text bound to checkbox labels
Collection surfaces	Forms and flows that trigger sensitive collection
Withdrawals	Downstream deletion jobs after opt-out
Blocks	Features disabled until consent or legal basis documented

Verdict: Art. 9 consent fails when health questions sit inside a generic signup checkbox—design isolated cards with explicit, unchecked opt-in.

---

Purpose registry (Art. 9 only)

SensitivePurposeRegistry — Explicit consent required · 6 purposes
├── wellness_health_metrics
│   ├── Categories: Health · Art. 9(2)(a) explicit consent
│   ├── Fields: sleep_hours, stress_score · Optional · Not required for core product
│   ├── Retention: 90d rolling · [Retention policy](/designing-data-retention-policies-and-auto-deletion-ui-in-figma/)
│   ├── Notice layer: Short card + link to full [privacy notice](/designing-privacy-notice-version-management-and-policy-changelog-ui-in-figma/)
│   └── Withdrawal: Stop collection + delete aggregates · [Withdrawal UI](/designing-consent-withdrawal-and-downstream-deletion-ui-in-figma/)
├── biometric_login
│   ├── Categories: Biometric · Separate from wellness · Link [biometric UI](/designing-biometric-data-collection-consent-and-processing-transparency-ui-in-figma/)
│   ├── Storage: Device-only vs server template · Copy must match architecture
│   └── Cannot combine with marketing consent on same screen
├── deib_optional_survey
│   ├── Categories: Racial/ethnic origin · Optional DEIB research · Aggregate-only reporting
│   ├── Prohibited: Required for account · HR sees individual rows without extra basis
│   └── k-anonymity: Block team views under n=5 · [Analytics controls](/designing-privacy-preserving-analytics-and-aggregation-controls-ui-in-figma/)
├── union_membership_benefits
│   ├── Categories: Trade union · B2B benefits partner only · Contract separate from consent
│   └── Show legal basis badge: Consent · Not "legitimate interest"
└── [ Add purpose ] · Legal review required · Auto-links [PIA/DPIA](/designing-privacy-impact-assessment-and-dpia-workflow-ui-in-figma/)

One purpose per consent card—never one checkbox covering health + marketing + analytics.

---

Explicit consent card (customer-facing)

ConsentCard — Wellness metrics · Separate from account creation · Step 2 of 2
├── Header: Optional · You can use Acme without this
├── Short notice: "We'd like to store sleep and stress scores to show personal trends."
├── Categories chip: Health data · Art. 9 explicit consent
├── Expand: Full notice · Processors · Retention 90d · No sale · [Privacy policy v4.2]
├── Checkbox: ☐ I consent to Acme processing my health data for wellness trends
│   └── Unchecked by default · Not tied to "Create account" button on same screen
├── Secondary: [ No thanks ] · Skips feature · No dark pattern · No nag for 30d
├── If checked: [ Continue ] · Records consent_id · policy_version · timestamp · surface_id
├── If parent account: Block until [children's gate](/designing-childrens-privacy-age-verification-and-parental-consent-ui-in-figma/) passes
└── Footer: Withdraw anytime in [Privacy settings](/designing-privacy-settings-and-data-management-ui-in-figma/)

No pre-checked boxes. No consent on terms-of-service scroll.

---

Layered notice pattern

LayeredNotice — wellness_health_metrics · v4.2
├── Layer 1 (card): One sentence purpose + category chip + optional badge
├── Layer 2 (expand): What we collect · Why · Who sees it · How long · Your rights
├── Layer 3 (policy): Full [privacy notice version](/designing-privacy-notice-version-management-and-policy-changelog-ui-in-figma/) section anchor
├── Version binding: consent_record stores notice_hash · Upgrades require re-consent if material
├── Localization: Same structure per locale · Legal review flag per translation
└── Accessibility: Expand is keyboard reachable · Category not color-only

Material changes trigger re-consent campaign UI—not silent checkbox reuse.

---

Consent proof ledger (admin)

ConsentLedger — User u_882 · Filter: Art. 9 only
├── CON-9912 · wellness_health_metrics · Granted 2026-06-14 09:12 UTC
│   ├── Policy: v4.2 · notice_hash: sha256:abc… · Surface: onboarding_step_2
│   ├── Evidence: checkbox_label text · locale en-US · ip_region: EU
│   ├── Withdrawn: — · Active: Yes
│   └── Export: [Compliance bundle](/designing-compliance-exports-and-legal-hold-ui-in-figma/)
├── CON-9918 · biometric_login · Granted 2026-07-01 · Device: Face · Template server-side
│   └── Link [passkeys UI](/designing-passkeys-and-passwordless-login-ui-in-figma/) if combined flows
├── CON-9920 · deib_optional_survey · Withdrawn 2026-08-01
│   ├── Withdrawal job: Completed · Rows deleted · Analytics resynced
│   └── Proof of deletion: job_id del_441 · [Audit log](/designing-audit-log-and-security-activity-ui-in-figma/)
└── [ Search by user ] · [ Bulk re-consent campaign ] · Immutable append-only store

Regulators ask for what the user saw—store label text and policy version, not just a boolean.

---

Withdrawal and downstream stop

WithdrawSensitive — Wellness metrics · Active since 2026-06-14
├── Copy: "Stop processing my health data and delete stored scores"
├── Impact preview:
│   ├── Wellness dashboard will hide · Trends archived per [retention](/designing-data-retention-policies-and-auto-deletion-ui-in-figma/)
│   ├── ML features using health traits disabled · 24h propagation
│   └── Billing unchanged · Core product unchanged
├── Confirm: Type DELETE or second checkbox · Prevent mis-tap
├── Jobs: ingestion_off · warehouse_purge · model_feature_drop · backup_ttl noted
├── Status: 3/4 complete · Backup purge scheduled day 30 · User email when done
└── Link [general consent withdrawal](/designing-consent-withdrawal-and-downstream-deletion-ui-in-figma/) for non-Art.9 scopes

Withdrawal UI must list concrete product impact—not generic “processing will stop.”

---

Comparison: explicit consent vs other legal bases

Basis	UI pattern	Pre-checked?	Example
Art. 9 explicit consent	Separate card	Never	Health trends opt-in
Contract	Required field with purpose	N/A (not consent)	Email for account
Legitimate interest	Notice + objection link	N/A	Fraud signals · LIA
Art. 6 consent (non-special)	Scoped toggle	Never	Marketing email
Legal obligation	Inform only	N/A	Tax ID where required
Vital interests	Rare · legal-only copy	N/A	Emergency medical

Never label Art. 9 flows as “optional preferences” without the category chip.

---

Handoff checklist (Dev Mode)

• SensitivePurpose — purpose_id, art9_categories[], fields[], retention_ref, notice_version.
• ConsentCard — surface_id, checkbox_label, default_checked false, skip_action, nag_cooldown_days.
• ConsentRecord — record_id, user_id, purpose_id, granted_at, policy_version, notice_hash, withdrawn_at.
• LayeredNotice — layer1_copy, expand_copy, policy_anchor, locale.
• WithdrawalJob — job_id, purpose_id, downstream_targets[], status, user_notification_template.
• CollectionBlock — feature_id, blocked_reason, missing_consent_type.
• Accessibility — consent checkbox independent; category chip readable; withdrawal confirm focus trap.

---

Common mistakes

Mistake	Why it hurts	Fix
Health questions on required signup	Invalid consent	Optional step after account
One checkbox for TOS + health	Not explicit	Separate Art. 9 card
Pre-checked sensitive consent	GDPR invalid	Default unchecked
Biometric + wellness same card	Mixed purposes	Split purposes in registry
No proof storage	Cannot defend audit	Ledger with notice_hash
Withdrawal without deletion jobs	Art. 7(3) breach	Job queue UI + status
DEIB survey required for HR view	Coercion	Optional + aggregate reporting
Minors without parental gate	Illegal collection	Age verify first

---

Recommended workflow

1. Register Art. 9 purposes in ROPA before designing any sensitive form (ROPA UI).
2. Run PIA/DPIA for new categories—link ticket in launch gates.
3. Design consent cards per purpose with layered notices and unchecked defaults.
4. Wire collection blocks—APIs return 403 until ConsentRecord exists.
5. Build proof ledger for admin and export to compliance evidence.
6. Design withdrawal with downstream job visibility (consent withdrawal).
7. Align minimization—drop sensitive fields not tied to an approved purpose (minimization UI).

---

FAQ

Art. 9 vs biometric consent UI?

Biometric login is one special category—use the dedicated biometric patterns; this hub covers all Art. 9 categories.

Same as cookie consent?

Cookies are usually Art. 6 ePrivacy—not a substitute for health or biometric explicit consent.

US state privacy laws?

Many align on sensitive data opt-in—reuse card layout; legal maps categories per region badge.

Employee HR data?

Workplace special-category rules differ—separate admin surfaces and bases; do not reuse consumer signup cards.

Research with special category data?

Add ethics review ID, aggregate-only export, and anonymization gates before sharing.

---

Next steps

• Design biometric data collection consent and processing transparency UI in Figma — device vs server templates
• Design consent records and preference management admin UI in Figma — unify Art. 6 and Art. 9 ledgers
• Design consent withdrawal and downstream deletion UI in Figma — stop processing after opt-out
• Design privacy by design launch gates and feature privacy review UI in Figma — block ship without Art. 9 review
• Design data minimization and purpose limitation UI in Figma — reject unnecessary sensitive fields