Accounts Center

Turning Regulatory Pressure into Strategic Infrastructure

Lead Product Designer, Privacy Design Strategy | 2020–2022

---

Executive Summary

Meta's privacy settings were fragmented across six apps — each with its own IA, terminology, and compliance interpretation. As GDPR enforcement intensified and the Digital Markets Act loomed, this wasn't just a user experience problem. It was a structural liability.

Rather than patching each app independently, I advocated for a different bet: redesign the underlying information architecture to create unified, cross-app account infrastructure — and in doing so, transform regulatory compliance from a reactive obligation into a durable platform advantage.

What began as a settings redesign became the foundation for Meta's cross-app account infrastructure, satisfied DMA interoperability requirements, and directly catalyzed the company's design system and corporate rebrand.

---

Role & Scope

• Title: Lead Product Designer, Privacy Design Strategy
• Level: IC6
• Team: 6 core privacy designers + federated design leadership across Instagram, Facebook, WhatsApp, Messenger, Oculus, Meta Horizon
• XFN Partners: Legal, Policy, Engineering, Product Management
• Organizational Reach: Privacy, Monetization, and Infrastructure teams

---

The Problem

A Settings Landscape Built for the Wrong Era

Meta's privacy settings reflected organizational structure, not user needs. Each app had been built independently, with its own privacy model, controls language, and compliance approach.

The user experience failure was predictable:

• Managing ad preferences required navigating four different interfaces with inconsistent terminology
• Downloading personal data meant submitting separate requests per app
• Privacy controls had no permanent, predictable home — they were scattered across help articles, app-specific settings, and contextual menus

The compliance risk was compounding:

• Each app interpreted GDPR requirements differently
• Cookie consent implementations varied across apps and EU member states, creating dozens of potential variation states
• No centralized data view meant no efficient path to satisfy user "right to access" requests
• DMA interoperability requirements were structurally impossible with siloed architecture

---

My Approach

Step 1 — IA Audit Before Any Proposals

Before making any recommendations, I mapped the full existing architecture. I reviewed the settings surfaces across all six apps — every screen, every entry point, every control — and conducted a comprehensive IA audit. The output was a design doc inventorying proposed taxonomy changes, information hierarchy restructuring, and the full scope of what a unified system would require.

This grounded all subsequent decisions in evidence, not opinion, and gave me the credibility to lead alignment conversations with teams who had ownership over their own surfaces.

Step 2 — A Virtual Team, Not a Top-Down Mandate

Getting six app teams aligned on a shared IA is an organizational design problem as much as a design problem. Rather than issuing proposals from the center, I built a virtual team: one design leader and one design manager from each of the six apps, meeting on a regular cadence.

We used natural design process mechanisms — critiques, working sessions, shared documentation — to build alignment iteratively. Each designer then took proposals back to their respective teams, creating distributed ownership rather than top-down adoption. Strategy was mine to lead; execution had shared authorship.

---

Key Design Decisions

1. Accounts Center as a Horizontal Platform, Not an In-App Surface

The early framing of Accounts Center positioned it as a surface within each app — another settings destination among many. I pushed for a different model: a horizontal surface that spanned across apps, with entry points from apps rather than living inside them.

This was not a cosmetic distinction. It changed the altitude at which Accounts Center sat in the entire product ecosystem. A surface within an app is always subordinate to that app's IA. A horizontal platform is infrastructure — it can evolve independently, scale across the Family of Apps, and serve as the durable home for cross-app account management. The optionalities I presented around the platform model ultimately drove the decision. This framing also set up the conditions for what became Meta's design system.

2. Privacy Settings Deserved a Permanent, Predictable Home

The team that would eventually own Accounts Center after federation preferred to keep the existing IA intact, sprinkling privacy settings across their current settings structure. Their position was reasonable: minimize disruption, preserve familiarity.

I held a different view. From a data transparency and user control perspective, privacy settings needed to be consolidated, not distributed. The goal was not just perceived control — through surfaces like Privacy Center or Privacy Checkup — but actual control: settings that were findable, predictable, and had a permanent address. The settings surface, from a UX perspective, is the most reliable location a user has for that kind of trust. We pulled privacy settings out into their own cohesive structure rather than absorbing them into the existing IA.

3. Ads Settings — Navigating First and Third-Party Complexity

One of the most contested scoping decisions involved ads settings. Ads controls existed in two forms: consolidated settings within the settings surface (under "Your Ads and Data") and contextual settings at the app level (e.g., a "Why am I seeing this ad?" menu in feed).

The question was how much to consolidate, and how to think about first-party versus third-party data controls in relation to what users could configure through each surface. This required navigating legal and policy constraints, engineering dependencies, and user comprehension — simultaneously. The outcome was a principled framework for what belonged in Accounts Center versus what remained contextual, with clear rationale for each decision.

---

Organizational Impact

Privacy Infrastructure — Accounts Center gave users across Meta's Family of Apps a centralized, unified location for privacy and account controls. The restructured IA satisfied DMA interoperability requirements and created a scalable compliance framework applicable across regulatory contexts.

Design System Catalyst — The cross-app IA work exposed the absence of a shared design language at company scale. The unified account infrastructure provided the perfect foundation — and timing aligned with Meta's corporate rebrand. Accounts Center directly catalyzed what became Meta's company-wide design system.

Monetization Enablement — Ads settings restructuring created transparent, user-facing controls for data collection, storage, and transport — satisfying regulatory requirements while protecting the ad infrastructure that drove company revenue.

Infrastructure Precedent — What began as a settings redesign became the backbone of Meta's cross-app account infrastructure, enabling connected experiences across the Family of Apps that were structurally impossible before.

---

Reflection

The highest-leverage decision I made on this project wasn't a design pattern or an IA taxonomy. It was the decision to build alignment across six app teams through distributed ownership rather than centralized mandate.

Design at platform scale is organizational design. The virtual team model, the shared cadence, the mechanism of taking proposals back to each app team — these weren't soft process decisions. They determined whether the work would actually ship and stick across a complex, multi-team organization.

The second insight: when you're working at the intersection of compliance, product infrastructure, and user experience, the design problem is almost never what it appears to be on the surface. Accounts Center looked like a settings redesign. It was actually an infrastructure problem that required design leadership to see and name.