Module 3 · Designing Consent UX

Last updated: April 29, 2026

Most DPDP compliance failures don’t happen at the database layer or the security layer — they happen at the pixel layer. A pre-ticked marketing box, a bundled “I agree to everything” checkbox, an unsubscribe link buried in a footer, a cookie banner with no “reject all” option. These are product decisions, not legal decisions. Which means the job of building DPDP-compliant consent falls on whoever ships interfaces — product managers, designers, frontend engineers.

This module gives you the patterns. Specific, screen-level, copy-level patterns that pass both DPDP review and usability testing. By the end, you will be able to review a signup flow, a cookie banner, or an email preferences page and spot every compliance gap — and know what pattern to replace each with.

The five consent tests — translated to UX

Section 6 of the DPDP Act says consent must be free, specific, informed, unconditional, unambiguous. Each of these tests is really a UX rule in disguise. Let’s translate:

Free — no coercion, no bundling

Consent is not free if the user had to give it to get a service they need. Concretely:

• Fails free: “Agree to our marketing emails OR pay ₹99 to skip” — the option to opt out exists but has a price. Coercive.
• Fails free: A signup form that bundles “I agree to Terms, Privacy Policy, Marketing, Analytics” into a single checkbox. You’re coercing marketing consent by bundling it with mandatory consents.
• Passes free: A signup form with one mandatory checkbox for Terms + Privacy, and a separate, unchecked-by-default optional toggle for marketing.

Specific — per-purpose consent

One consent, one purpose. Concretely:

• Fails specific: “I consent to RingSafe processing my data for marketing, analytics, product improvement, personalisation, partner offers, and fraud prevention.” That’s six purposes in one checkbox.
• Passes specific: Six separate toggles, one per purpose, each with its own description. The user can enable marketing, decline analytics, enable personalisation.

Informed — user understands what they’re agreeing to

Concretely:

• Fails informed: “I agree to the Privacy Policy” — where the Privacy Policy is a 5,000-word legal document linked in a tiny font. The Data Principal cannot reasonably read and understand it in the moment of consenting.
• Passes informed: Short, plain-language summary of the key processing next to the consent checkbox, with a “read full policy” link for those who want depth. Critical details (what data, where it goes, who sees it, retention) summarised in under 100 words.

Unconditional — no quid pro quo

Consent for processing that is not strictly needed for the service cannot be a condition of accessing the service. Concretely:

• Fails unconditional: “You cannot use this app unless you consent to analytics tracking.” Analytics is not strictly needed to deliver the app; making it a condition violates Section 7.
• Passes unconditional: The app works fully with analytics disabled. Analytics consent is a separate, optional toggle.

Unambiguous — affirmative action, no pre-ticked boxes, no “implied by continued use”

• Fails unambiguous: “By continuing to use our site, you consent to cookies.” No affirmative action.
• Fails unambiguous: A pre-ticked marketing checkbox that the user has to untick.
• Passes unambiguous: An empty checkbox the user must actively tick. Or an off-by-default toggle the user must actively flip to on.