Led the Privacy UX for a live global event that reached 22 million fans, translating GDPR, CCPA, and COPPA into design every team could build.
Company
Warner Bros. Entertainment
Timeline
2020
Role
UX Designer, Privacy & Data Strategy
Context
Comic-Con wasn’t happening and Warner Bros. answered with DC FanDome, a live global virtual event that reached 22 million fans, launching seven weeks after CCPA enforcement began. I came in as the UX designer responsible for translating legal privacy requirements into clear actionable direction for teams across Product, Technology, Marketing, Creative Vendors, and Executives.
Challenge
Warner Bros. was still working out how to bring a sprawling technology portfolio into CCPA compliance. The law had teeth now, with penalties assessed per violation and per consumer. But there was no established playbook yet for what a signup form or a data request flow had to do to comply, or which team was on the hook for building it.
CCPA was only part of it. DC FanDome was built for a global audience, which meant GDPR applied across Europe, CCPA in California, and COPPA anywhere children could reach an experience. The requirements were not the same, and neither were the consent models behind them. Before I could tell a team what they needed to build, I had to know which territories their experience was going out to. Not every team knew.
Privacy Legal wasn't looped in until most teams were already deep into build, some of them nearly finished. Privacy was being retrofitted, not designed in.
Accessibility landed the same way. The Head of Accessibility was brought in late too, on the same nearly-finished builds, to check the experience against ADA and WCAG standards (keyboard navigation, screen reader support, color contrast, the things that determine whether a person with a disability can actually use a page).
And this was live. A 24-hour global broadcast with no staged rollout and no quiet window to push a fix. Whatever shipped wrong stayed wrong in front of the entire audience. On an event this publicized, with a fanbase this engaged, a privacy misstep wouldn't have stayed an internal compliance matter. It would have been a story.
Multiple regulatory regimes, requirements arriving after the work was mostly built, nobody clearly on the hook, and one shot to get it right. That was the real challenge. Not a hard design problem. A hard organizational one, with about four weeks to solve it.
My Role
I was the connective tissue between people who knew what the law required and people who were building the experience.
That meant working across the company:
On the compliance side: the VP, Privacy Counsel for WarnerMedia, along with Privacy Legal, Privacy Tech, WB Technology, and Security. This is where requirements came from.
On the build side: product owners across DC Universe and DC Comics, TV Marketing, Theatrical Marketing, WB Games, internal product design teams, and external vendors contracted to build individual experiences. This is where the actual data collection was happening.
Alongside all of it: Production, Talent, Animation, and Editorial, all building in parallel, plus the Head of Accessibility, who was reviewing many of the same screens I was.
A lot of my early work wasn't design at all. It was finding out who owned what. Some experiences were built by internal teams. Some by vendors. Some by marketing groups who had never been through a privacy review. Before I could ask anyone what data they were collecting, I had to find the person who could answer.
Process
1. Map everything.
DC FanDome wasn't one experience. It was many, stacked inside each other. A main hub, separate themed worlds, a dedicated kids' environment, live streams, fan feeds, a fan-content submission tool, watch parties, games, quizzes, merchandise, social integrations, sweepstakes, and email signups, each with its own build team and its own reasons for collecting something from a fan.
I traced all of it end to end. Every place a fan entered data, every place data was captured from a browser or passed to a backend, across every world inside FanDome and every division building one. Before I could map it, I had to understand what each experience actually was and how a fan moved through it. I also had to establish where each one was going, since the territories an experience served determined which regime applied to it.
The map wasn't the deliverable. It was how I found out how much nobody knew.
2. Find the owners.
For each touchpoint, I traced it back to a person who could speak to it. That meant chasing email threads through marketing teams, product teams, and vendor contacts, sometimes several handoffs deep. This was unglamorous but it was the single most useful thing I did, because everything downstream depended on it.
3. Translate in both directions.
Product teams could tell me what they were collecting and why. They could not tell me what CCPA or GDPR required of them. Legal could tell me what each regime required. They could not see what any given team was building, or where it was going. I sat in the middle: gathering data collection details and target territories from product and marketing, bringing them to Privacy Legal for guidance, then carrying requirements back to teams already deep into build.
The second half was harder than the first. Telling a team that's nearly done that they need to add a consent flow requires more than forwarding a legal requirement. It requires explaining why, in terms that make sense to someone who has a launch date. It also meant translating requirements written as legal obligations into decisions a designer could act on: what the control is, where it goes in the flow, what it says, and what happens when someone declines.
As the UX Designer for Privacy & Data Strategy, it was vital for me to communicate that the experience being shipped needed to align with the company-wide Privacy Design UX specifications, which we had rigorously designed and refined for an optimal consumer data experience.
4. Make one pattern hold everywhere.
The privacy guidance that existed was a long Word document: legal language, screenshots, requirements written for lawyers. No specs, no component definitions, nothing a product designer could pick up and build from. Every team that received it had the same reaction, which was to not know what to do with it.
So I became the interpreter. I sat with product designers and walked them through what the document actually required of their specific screen, then connected them to the tech people who could implement it. I did this team by team, vendor by vendor.
The goal was one consent pattern that behaved predictably everywhere: same placement logic, same interaction model, same posture toward the fan, whether they hit it in the main hub or inside an experience an outside vendor had built. But it couldn't be one rigid template, because the regimes don't ask for the same thing. GDPR expects consent before collection. CCPA is built around notice and the right to opt out. So the pattern had to hold its shape while flexing by territory, and each team had to know which version applied to them.
Getting that consistency across teams with no shared design process, no shared component library, and no shared vocabulary was the hardest part of the job, and the part most like the design systems work I do now. The adoption problem was the design problem.
5. Solve the kids' problem by subtraction.
KidsVerse was a different animal. Children's data isn't governed by CCPA, it's governed by COPPA, which is older, stricter, and unforgiving: verifiable parental consent, hard limits on what you can collect, no behavioral advertising. Building a compliant consent flow for children is possible, but it's genuinely difficult, and doing it well in four weeks alongside everything else was not realistic.
The recommendation that came out of that review was to remove logins and data collection from KidsVerse entirely. If you don't collect it, you can't mishandle it. The experience stayed. The risk went away.
That was the clearest lesson of the project for me. The best privacy design is often less product, not more controls. Consent flows are what you build when you've already decided you need the data. The question worth asking first is whether you do.
6. QA as I went.
I came up through customer support at Warner Bros., answering phones and turning consumer complaints into product recommendations. That background is hard to switch off. Reviewing privacy flows meant clicking through the experiences anyway, and while I was in there I would find small things that would trip a fan up: a modal that didn't dismiss cleanly, a form field behaving oddly, a link pointing somewhere it shouldn't. I logged them and escalated them to dev teams even though QA wasn't my assignment.
The Head of Accessibility gave me a crash course in WCAG around the same time, since she was reviewing the same screens I was. It wasn't my deliverable, but once I knew what to look for I kept an eye out while I worked and flagged anything questionable to her, particularly on the consent and data collection screens. A consent modal that can't be navigated by keyboard isn't a real choice.
7. Track it to closure.
With this many teams building in parallel, nothing could be assumed compliant until it was verified. I tracked every requirement against every implementation and audited pieces as they came online, right up to launch. There was no post-launch cleanup window on a live 24-hour broadcast, so verification had to happen before the doors opened.
Solution
Privacy UX was successfully designed into the complete DC FanDome experience.
Consent flows and OneTrust modals shipped consistently across every division's experience, working the same way regardless of whether an internal team or an external vendor built the page, and adapting to whichever regime applied in a given territory. Data requests were simplified so fans understood what they were agreeing to. KidsVerse shipped without logins or data collection at all. Every touchpoint I had mapped had a documented owner and a verified control behind it before launch.
That last part is what kept Warner Bros. out of trouble. CCPA and GDPR both assess penalties per violation, and GDPR scales them against global revenue, so a single consent flow shipping wrong across an audience this size wouldn't have been a small problem. Getting it right wasn't visible to a single fan, which was the point. Good privacy design doesn't announce itself. It just means the choice you were offered was a real one.
Results
DC FanDome reached 22 million fans across 220 countries in 24 hours.
The privacy work held. On an event with this many data touchpoints, this many teams, and this little runway after CCPA took effect, there were no post-launch privacy escalations. For a company still working out what compliance looked like in practice, DC FanDome became a working answer.
It also surfaced what was missing. Every time I had to translate that Word document for another product designer, it was evidence that the guidance didn't work in the form it existed in. Those gaps fed directly into the privacy design system runbook WarnerMedia built afterward, which I would go on to help steward. We knew what it needed to contain because we had spent four weeks running into every place the old version fell short.
I was trusted with this work directly by WarnerMedia's Legal General Counsel.
When the credits ran, I was listed twice: once with the Privacy and Data Strategy team, and once with QA. I was never officially on the QA team. I just kept finding small things that would have bothered a fan, and telling people about them.
What I Took From It
DC FanDome was my crash course in privacy law, privacy operations, and what compliance actually asks of a product team. I came out of it with one conviction that has shaped how I work since.
Privacy and accessibility are stakeholders, not checkpoints. Both showed up here after the builds were nearly done, and the cost of that was enormous: rework, renegotiation, and precious time spent explaining requirements to people who would have designed around them happily if anyone had said so upfront. It costs far less to bring Legal and Accessibility in during discovery than to retrofit their requirements into a finished product.
The version of that I now argue for is simple. Every project should carry a persona for the person who wants their data handled properly, and a persona for the person who needs assistive technology to use the thing at all. Not a compliance review at the end. A seat at the table at the start.
I took that directly into my next project: the WarnerMedia Privacy Center, where I redesigned how people request their data and, just as importantly, made the file they get back something a human being can actually read.
More projects
Led the Privacy UX for a live global event that reached 22 million fans, translating GDPR, CCPA, and COPPA into design every team could build.
Company
Warner Bros. Entertainment
Timeline
2020
Role
UX Designer, Privacy & Data Strategy
Context
Comic-Con wasn’t happening and Warner Bros. answered with DC FanDome, a live global virtual event that reached 22 million fans, launching seven weeks after CCPA enforcement began. I came in as the UX designer responsible for translating legal privacy requirements into clear actionable direction for teams across Product, Technology, Marketing, Creative Vendors, and Executives.
Challenge
Warner Bros. was still working out how to bring a sprawling technology portfolio into CCPA compliance. The law had teeth now, with penalties assessed per violation and per consumer. But there was no established playbook yet for what a signup form or a data request flow had to do to comply, or which team was on the hook for building it.
CCPA was only part of it. DC FanDome was built for a global audience, which meant GDPR applied across Europe, CCPA in California, and COPPA anywhere children could reach an experience. The requirements were not the same, and neither were the consent models behind them. Before I could tell a team what they needed to build, I had to know which territories their experience was going out to. Not every team knew.
Privacy Legal wasn't looped in until most teams were already deep into build, some of them nearly finished. Privacy was being retrofitted, not designed in.
Accessibility landed the same way. The Head of Accessibility was brought in late too, on the same nearly-finished builds, to check the experience against ADA and WCAG standards (keyboard navigation, screen reader support, color contrast, the things that determine whether a person with a disability can actually use a page).
And this was live. A 24-hour global broadcast with no staged rollout and no quiet window to push a fix. Whatever shipped wrong stayed wrong in front of the entire audience. On an event this publicized, with a fanbase this engaged, a privacy misstep wouldn't have stayed an internal compliance matter. It would have been a story.
Multiple regulatory regimes, requirements arriving after the work was mostly built, nobody clearly on the hook, and one shot to get it right. That was the real challenge. Not a hard design problem. A hard organizational one, with about four weeks to solve it.
My Role
I was the connective tissue between people who knew what the law required and people who were building the experience.
That meant working across the company:
On the compliance side: the VP, Privacy Counsel for WarnerMedia, along with Privacy Legal, Privacy Tech, WB Technology, and Security. This is where requirements came from.
On the build side: product owners across DC Universe and DC Comics, TV Marketing, Theatrical Marketing, WB Games, internal product design teams, and external vendors contracted to build individual experiences. This is where the actual data collection was happening.
Alongside all of it: Production, Talent, Animation, and Editorial, all building in parallel, plus the Head of Accessibility, who was reviewing many of the same screens I was.
A lot of my early work wasn't design at all. It was finding out who owned what. Some experiences were built by internal teams. Some by vendors. Some by marketing groups who had never been through a privacy review. Before I could ask anyone what data they were collecting, I had to find the person who could answer.
Process
1. Map everything.
DC FanDome wasn't one experience. It was many, stacked inside each other. A main hub, separate themed worlds, a dedicated kids' environment, live streams, fan feeds, a fan-content submission tool, watch parties, games, quizzes, merchandise, social integrations, sweepstakes, and email signups, each with its own build team and its own reasons for collecting something from a fan.
I traced all of it end to end. Every place a fan entered data, every place data was captured from a browser or passed to a backend, across every world inside FanDome and every division building one. Before I could map it, I had to understand what each experience actually was and how a fan moved through it. I also had to establish where each one was going, since the territories an experience served determined which regime applied to it.
The map wasn't the deliverable. It was how I found out how much nobody knew.
2. Find the owners.
For each touchpoint, I traced it back to a person who could speak to it. That meant chasing email threads through marketing teams, product teams, and vendor contacts, sometimes several handoffs deep. This was unglamorous but it was the single most useful thing I did, because everything downstream depended on it.
3. Translate in both directions.
Product teams could tell me what they were collecting and why. They could not tell me what CCPA or GDPR required of them. Legal could tell me what each regime required. They could not see what any given team was building, or where it was going. I sat in the middle: gathering data collection details and target territories from product and marketing, bringing them to Privacy Legal for guidance, then carrying requirements back to teams already deep into build.
The second half was harder than the first. Telling a team that's nearly done that they need to add a consent flow requires more than forwarding a legal requirement. It requires explaining why, in terms that make sense to someone who has a launch date. It also meant translating requirements written as legal obligations into decisions a designer could act on: what the control is, where it goes in the flow, what it says, and what happens when someone declines.
As the UX Designer for Privacy & Data Strategy, it was vital for me to communicate that the experience being shipped needed to align with the company-wide Privacy Design UX specifications, which we had rigorously designed and refined for an optimal consumer data experience.
4. Make one pattern hold everywhere.
The privacy guidance that existed was a long Word document: legal language, screenshots, requirements written for lawyers. No specs, no component definitions, nothing a product designer could pick up and build from. Every team that received it had the same reaction, which was to not know what to do with it.
So I became the interpreter. I sat with product designers and walked them through what the document actually required of their specific screen, then connected them to the tech people who could implement it. I did this team by team, vendor by vendor.
The goal was one consent pattern that behaved predictably everywhere: same placement logic, same interaction model, same posture toward the fan, whether they hit it in the main hub or inside an experience an outside vendor had built. But it couldn't be one rigid template, because the regimes don't ask for the same thing. GDPR expects consent before collection. CCPA is built around notice and the right to opt out. So the pattern had to hold its shape while flexing by territory, and each team had to know which version applied to them.
Getting that consistency across teams with no shared design process, no shared component library, and no shared vocabulary was the hardest part of the job, and the part most like the design systems work I do now. The adoption problem was the design problem.
5. Solve the kids' problem by subtraction.
KidsVerse was a different animal. Children's data isn't governed by CCPA, it's governed by COPPA, which is older, stricter, and unforgiving: verifiable parental consent, hard limits on what you can collect, no behavioral advertising. Building a compliant consent flow for children is possible, but it's genuinely difficult, and doing it well in four weeks alongside everything else was not realistic.
The recommendation that came out of that review was to remove logins and data collection from KidsVerse entirely. If you don't collect it, you can't mishandle it. The experience stayed. The risk went away.
That was the clearest lesson of the project for me. The best privacy design is often less product, not more controls. Consent flows are what you build when you've already decided you need the data. The question worth asking first is whether you do.
6. QA as I went.
I came up through customer support at Warner Bros., answering phones and turning consumer complaints into product recommendations. That background is hard to switch off. Reviewing privacy flows meant clicking through the experiences anyway, and while I was in there I would find small things that would trip a fan up: a modal that didn't dismiss cleanly, a form field behaving oddly, a link pointing somewhere it shouldn't. I logged them and escalated them to dev teams even though QA wasn't my assignment.
The Head of Accessibility gave me a crash course in WCAG around the same time, since she was reviewing the same screens I was. It wasn't my deliverable, but once I knew what to look for I kept an eye out while I worked and flagged anything questionable to her, particularly on the consent and data collection screens. A consent modal that can't be navigated by keyboard isn't a real choice.
7. Track it to closure.
With this many teams building in parallel, nothing could be assumed compliant until it was verified. I tracked every requirement against every implementation and audited pieces as they came online, right up to launch. There was no post-launch cleanup window on a live 24-hour broadcast, so verification had to happen before the doors opened.
Solution
Privacy UX was successfully designed into the complete DC FanDome experience.
Consent flows and OneTrust modals shipped consistently across every division's experience, working the same way regardless of whether an internal team or an external vendor built the page, and adapting to whichever regime applied in a given territory. Data requests were simplified so fans understood what they were agreeing to. KidsVerse shipped without logins or data collection at all. Every touchpoint I had mapped had a documented owner and a verified control behind it before launch.
That last part is what kept Warner Bros. out of trouble. CCPA and GDPR both assess penalties per violation, and GDPR scales them against global revenue, so a single consent flow shipping wrong across an audience this size wouldn't have been a small problem. Getting it right wasn't visible to a single fan, which was the point. Good privacy design doesn't announce itself. It just means the choice you were offered was a real one.
Results
DC FanDome reached 22 million fans across 220 countries in 24 hours.
The privacy work held. On an event with this many data touchpoints, this many teams, and this little runway after CCPA took effect, there were no post-launch privacy escalations. For a company still working out what compliance looked like in practice, DC FanDome became a working answer.
It also surfaced what was missing. Every time I had to translate that Word document for another product designer, it was evidence that the guidance didn't work in the form it existed in. Those gaps fed directly into the privacy design system runbook WarnerMedia built afterward, which I would go on to help steward. We knew what it needed to contain because we had spent four weeks running into every place the old version fell short.
I was trusted with this work directly by WarnerMedia's Legal General Counsel.
When the credits ran, I was listed twice: once with the Privacy and Data Strategy team, and once with QA. I was never officially on the QA team. I just kept finding small things that would have bothered a fan, and telling people about them.
What I Took From It
DC FanDome was my crash course in privacy law, privacy operations, and what compliance actually asks of a product team. I came out of it with one conviction that has shaped how I work since.
Privacy and accessibility are stakeholders, not checkpoints. Both showed up here after the builds were nearly done, and the cost of that was enormous: rework, renegotiation, and precious time spent explaining requirements to people who would have designed around them happily if anyone had said so upfront. It costs far less to bring Legal and Accessibility in during discovery than to retrofit their requirements into a finished product.
The version of that I now argue for is simple. Every project should carry a persona for the person who wants their data handled properly, and a persona for the person who needs assistive technology to use the thing at all. Not a compliance review at the end. A seat at the table at the start.
I took that directly into my next project: the WarnerMedia Privacy Center, where I redesigned how people request their data and, just as importantly, made the file they get back something a human being can actually read.