Jio

Consent Platform

Designing the system behind consent across an ecosystem

Industry

Jio ecosystem · web · mobile

Platform

B2B Web App

Duration

8-10 Weeks

Why this was hard

India's Digital Personal Data Protection Act doesn't just say “get consent.” It says consent has to be free, specific, informed, unconditional and unambiguous, given by clear affirmative action. People can withdraw at any time, and withdrawal has to be as easy as giving it was . Notices must be plain, standalone, itemised by data type and purpose, and available in any of the 22 languages in the Constitution's Eighth Schedule.

Then the part most teams miss. Every one of those interactions has to be provable — months later, to a regulator, under serious penalties.

reached support

opened a query

got to an agent or bot

dropped at the product section

Research & Discovery

So this was never a consent banner. It was a system that captures a choice, enforces it downstream in real time, and can reconstruct exactly what a person agreed to and when.

MeitY's brief for the challenge made the enforcement side explicit: verify consent through secure APIs before personal data is collected or used, and block a request immediately if consent is missing, expired or withdrawn.

The business problem:

14 in-depth user interviews across 5 partner groups — deliberately including partners who quit
Groups: active resellers, new resellers, stuck resellers (abandoned midway), enterprise platform partners, internal sales stakeholders
Gap analysis — mapping user needs at each journey stage vs what the platform offered
Support ticket + KAM call log analysis — what were partners actually calling about
Journey mapping across all 7 stages from signup to incentive payout

14 in-depth user interviews across 5 partner groups — deliberately including partners who quit
Groups: active resellers, new resellers, stuck resellers (abandoned midway), enterprise platform partners, internal sales stakeholders
Gap analysis — mapping user needs at each journey stage vs what the platform offered
Support ticket + KAM call log analysis — what were partners actually calling about
Journey mapping across all 7 stages from signup to incentive payout

The market we were entering

Consent tooling is an established global category — roughly $1.07 billion in 2026, growing at about 17% a year toward $2.34 billion by 2031. But almost all of it was built for GDPR and CCPA, with India added later as one jurisdiction among dozens.

That matters because DPDP isn't a variation on GDPR. It asks for things a European cookie banner was never designed to do.

Our position was specific: DPDP-native like the Indian entrants, but multi-tenant and built inside an ecosystem that had to comply with the Act itself before selling the solution to anyone else.

Two users who don't think alike

A compliance officer thinks in templates, purposes, retention rules, SLAs and audit trails.

A person thinks: who has my Aadhaar, and how do I make them stop?

They're looking at the same records. The design problem was serving both from one data model without turning the citizen's experience into an admin console, or the admin console into something too simple to be compliant.

And a third constraint

This wasn't only for Jio. The platform is multi-tenant — configured per business, with the roadmap pointing at organisations outside the group entirely. The admin configures what the citizen sees, down to the branding of the privacy centre.

The same consent record, seen by the two people who care about it.

What I designed against

There was no discovery phase on this project, and pretending otherwise would misrepresent it. The constraints were fixed before design started — by the Act, by MeitY's brief, by accessibility standards, and by the decision to build for any organisation rather than just for Jio.

So the research work was reading the regulation closely enough to know what each clause forced, then designing responses that held up. Every row below is checkable.

Information architecture

Twenty-five admin screens across six domains. The organising decision was to keep operational work and evidence on separate surfaces — a compliance officer chasing a grievance SLA and an auditor reconstructing a consent history are doing different jobs, and merging them produces a screen that serves neither.

Consent is a state, not a checkbox

Four decisions, and what each one cost

Configuration before data

A new admin lands on an empty dashboard with two actions: configure the system, or create a business group. Nothing renders until the tenancy model exists.

What it cost: a cold start. Someone evaluating the product sees nothing working on day one. I took that because placeholder data in a compliance tool is worse than an honest empty state — an officer who can't trust the numbers can't use the product at all.

A new admin lands on an empty dashboard with two actions: configure the system, or create a business group. Nothing renders until the tenancy model exists.

Business group as the top-level scope, on every screen

It sits above the navigation, not inside settings.

What it cost: an extra concept for a single-tenant organisation that will never need it. In exchange, one product serves one company or a whole ecosystem without a separate build.

It sits above the navigation, not inside settings.

What it cost: an extra concept for a single-tenant organisation that will never need it. In exchange, one product serves one company or a whole ecosystem without a separate build.

Templates rather than bespoke consent forms

Consent is configured as reusable templates carrying purpose, validity and required-versus-optional flags, then instantiated per surface.

What it cost: less flexibility at any single consent moment. It's what makes a notice reproducible in an audit — you can point at the exact template version a person saw.

Consent is configured as reusable templates carrying purpose, validity and required-versus-optional flags, then instantiated per surface.

What it cost: less flexibility at any single consent moment. It's what makes a notice reproducible in an audit — you can point at the exact template version a person saw.

Grievance as a configurable workflow, not a mailbox

Types, forms, SLA targets and escalation to a named Data Protection Officer.

What it cost: real setup burden before the first grievance ever arrives. But the Act requires fulfilment within 30 days, so an inbox someone remembers to check is a compliance failure waiting to happen.

Types, forms, SLA targets and escalation to a named Data Protection Officer.

What shipped: Admin Portal

The console covers the full compliance surface, not just consent collection.

Jio Consent User Website

What shipped: User Portal

The citizen's half. Granted consents, pending requests, grievance redressal, and requests.

Looking back

What worked

Reading the regulation as a design brief rather than a legal appendix. Every clause in the Act that mentions the user — withdrawal symmetry, plain language, itemised purposes, grievance timelines — is a UX requirement wearing legal clothes, and treating it that way produced better answers than treating compliance as something to satisfy after the design was done.

Modelling consent as explicit states rather than a boolean. It made the enforcement contract unambiguous for engineering and made the audit story possible at all.

What I'd do differently

Candidates from what the work shows: the cold-start problem for a first-time admin; whether templates were the right granularity; getting the multilingual variants designed rather than specified; testing the privacy centre with people who aren't privacy-literate.