Enter password
Email gaeul.leee@gmail.com for access.
Building WhatsApp's first scalable enforcement system
I led the design of WhatsApp's first scalable enforcement system, turning urgent regulatory requirements into a modular experience for transparency, appeals, reporting, and remediation. Built for Channels, scaled across accounts, groups, and communities.
- 13 compliance projects shipped in one year
- ~50% reduction in engineering effort
- 64+ enforcement scenarios supported
- 8 components, 5 patterns, 50+ configurable properties
- Adopted across multiple WhatsApp surfaces
Channels changed
WhatsApp's integrity model
In 2023, WhatsApp launched Channels, its first non-encrypted public surface. Content could now reach huge audiences, which meant enforcement could no longer stay invisible.
E2EE
Private messaging
Encrypted end-to-end, one-to-one, smaller reach, and limited need for public content governance.
Public
Channels
Public broadcast, one-to-many, higher amplification risk, and the need for transparent enforcement and reporting.
At the same time, the EU Digital Services Act required user-facing transparency, appeals, and reporting visibility, and none of it existed yet.
- 01
Transparency
Inform users about the reason for enforcement.
- 02
Information
Share additional details about users’ rights.
- 03
Appeal
Allow users to appeal enforcement decisions.
- 04
Reporting
Show the status and result of reports.
Shipped the first enforcement
journey under DSA pressure
I designed the first version end to end: notification, enforcement details, remediation, appeal, and outcome. It met the DSA deadline, but shipping it revealed this couldn't remain a one-off product flow.
Foundational enforcement journey
Notification → Enforcement details → Remediation → Appeal outcome
One-off compliance
flows wouldn't hold up
After v1 shipped, I looked across WhatsApp's broader enforcement landscape and saw the same suspension action presented four different ways across accounts, groups, communities, and channels. The user mental model was consistent. The product experience was not.
Inconsistent treatments across surfaces
Same action, four different treatments across accounts, groups, communities, and channels.
Whether users faced a suspension, geo-block, removal, report outcome, or appeal, they were asking the same five questions:
- 01
What happened?
- 02
Why did it happen?
- 03
What does it mean for me?
- 04
What can I do next?
- 05
What happens after I act?
Build the enforcement
model once, then configure it
I reframed the work from a series of compliance projects into one reusable enforcement system. Instead of designing a new journey every time a rule landed, I proposed configurable modules that could adapt across entities, violations, geographies, severities, and remediation paths.
Mapping the framework to the user's mental model
Each stage reuses the same components, patterns, and CTAs, so any enforcement scenario can be assembled from the same building blocks.
Proving the system before
asking the org to commit
A modular system was a big ask, so I needed proof first. I piloted one configurable remediation module that engineering estimated could cut future build time by ~50%, which turned modularization from a design preference into an operational decision.
Before
Bespoke remediation
Remediation actions were handled as bespoke CTAs, varying by enforcement type. Each new option required custom implementation, creating inconsistent flows that were hard to scale.
After
Configurable remediation
I replaced bespoke CTAs with a single See options entry point. The next screen dynamically shows available remediation options based on the enforcement type, so teams can configure options instead of rebuilding the flow.
From there, I built a tailored buy-in process across leadership, legal, policy, engineering, design, and content. Each group got a different argument: regulatory confidence, consistency, effort reduction, app-size control, user clarity, or long-term maintainability.
PD & CD managers
Concept clarity
- Artifact:
- Initial concept
- Outcome:
- Design roadmap
PM
User problem and scope
- Artifact:
- Journey map and pain points
- Outcome:
- Product direction
Engineering
Feasibility and savings
- Artifact:
- Milestones and effort estimate
- Outcome:
- Engineering roadmap
Partner PMs
Relevance to their surfaces
- Artifact:
- Framework mapped to their problems
- Outcome:
- Adoption interest
Pillar leads
Business and company value
- Artifact:
- Benefits and success metrics
- Outcome:
- Product roadmap
Build review
Execution confidence
- Artifact:
- Pixel-level details and milestones
- Outcome:
- Launch approval
PD & CD managers
Concept clarity
- Artifact:
- Initial concept
- Outcome:
- Design roadmap
PM
User problem and scope
- Artifact:
- Journey map and pain points
- Outcome:
- Product direction
Engineering
Feasibility and savings
- Artifact:
- Milestones and effort estimate
- Outcome:
- Engineering roadmap
Partner PMs
Relevance to their surfaces
- Artifact:
- Framework mapped to their problems
- Outcome:
- Adoption interest
Pillar leads
Business and company value
- Artifact:
- Benefits and success metrics
- Outcome:
- Product roadmap
Build review
Execution confidence
- Artifact:
- Pixel-level details and milestones
- Outcome:
- Launch approval
Clear, actionable, and built to scaleThree principles shaped
every enforcement moment
Principle 1
Transparent
Show people what happened, why it happened, and what the decision was based on.
Principle 2
Actionable
Give users a clear way forward, whether that's fixing the issue, choosing a remediation option, or appealing.
Principle 3
Scalable
Support new entities, regulations, and enforcement types without rebuilding the experience every time.
Six reusable moments
for any enforcement scenario
Instead of designing separate flows for every enforcement type, I grouped the system into reusable moments: alert, evidence, options, appeal, explanation, and outcome. Each moment could be configured by entity, violation type, location, decision source, and available remediation paths.
01
Enforcement summary
What happened, when, and which entity was affected. A consistent header pattern gives users the immediate state of enforcement before they read the details.
02
Evidence and reason
Why action was taken and what content triggered it. The detail view connects policy context with the specific update or signal behind the decision.
03
Remediation options
What users can do next. A configurable options page shows available actions such as deletion, appeal, dispute settlement, or policy education.
04
Appeal submission
How users can ask for another review. The appeal flow sets expectations clearly: what will be reviewed, who reviews it, and what may happen next.
05
Decision transparency
How the enforcement decision was made. A reusable explanation pattern clarifies whether technology, review, or policy rules contributed to the decision.
06
Review outcome
What changed after the review. Outcome details close the loop by explaining the result, affected content, and remaining next steps.
Three decisions that shaped
how enforcement feels
The system couldn't just be efficient for teams. It had to make difficult enforcement moments easier for users to understand, act on, and learn from.
DETAIL 1
Reframe enforcement from blame to explanation
Admins often took enforcement personally, especially when it affected a public channel, brand, or creator identity. Neutral entity-level framing, a concise summary, and a less punitive visual treatment kept the message clear without feeling like a personal judgment.
DETAIL 2
Make transparency actionable
Transparency wasn't enough if users still had to search for what to do next. Connecting the reason, evidence, policy context, and remediation options in one flow let users move from understanding the decision to acting on it.
DETAIL 3
Design for repeat prevention
A resolved enforcement didn't always mean the user understood the rule. Contextual policy education helped admins learn the specific violation and avoid repeating it, shifting enforcement from reactive to proactive.
One consistent experience
across the full lifecycle
Enforcement details
Users access enforcement details through a clear entry point. The page explains what happened, why action was taken, what evidence was used, and what policy applies.
Remediation and appeals
Users have one place to review available options and take action, whether that's appealing, deleting content, learning more, or following remediation guidance.
Reporting transparency
Users who report content can track the status and outcome of their reports, creating a more accountable reporting experience.
From Channels enforcement
to a WhatsApp-wide system
The system started with Channels, but it was designed to scale from day one. Once the framework proved its value, it expanded to account, group, and community enforcement, becoming a broader integrity product system.
A new operating model
New enforcement needs are configured through shared modules instead of rebuilt as standalone flows.
I partnered with the Design System team to formalise the patterns, write the documentation, build the Figma library, and onboard other teams.
Formalised in the design system
Patterns, docs, and Figma library shared with every adopting team.
Turning design logic into reusable infrastructure
I prototyped the modular enforcement system in code so teams could see how components, states, and configurations would scale beyond one surface.
The biggest outcome was
a new operating model
Before this work, each new regulation risked becoming a new product build. After it, teams could ask a better question: which modules does this scenario need, and how should they be configured?
0
compliance projects shipped in one year
~0%
reduction in engineering effort per build
0+
enforcement scenarios supported across WhatsApp surfaces