Centralizing Privacy Tracker Governance
Enterprise UX | Internal Enterprise Tool | Workflow Design | 0→1| GRC / Compliance | Privacy & Compliance
Overview
A global SaaS company with multiple products relied on spreadsheets, emails, and Slack to track every “tracker” (cookies, pixels, SDKs) collecting user data across its platforms. There was no single source of truth, no audit trail and rising exposure to regulations like GDPR and CCPA. I led the design of a centralised governance platform - from discovery through the full request - to -remediation lifecycle.
The Business problem
No visibility
No consolidated view of trackers across products or their compliance status.
Manual process
Requests raised via forms, email, spreadsheets, Slack — no standard path.
Compliance risk
No standardized review = higher exposure to GDPR / CCPA penalties.
No accountability
Nothing tracked pending vs. approved vs. rejected, or who owned what.
Hypothesis: a centralized UI for submitting, approving, and monitoring trackers improves privacy-team efficiency, reduces manual work, and closes compliance gaps across every product.
My Role
-
Solo designer, end-to-end: discovery, personas, lifecycle mapping, and every persona’s view
-
Worked directly with Privacy, Legal, Domain Owners, and Engineering
-
Turned ambiguous, conflicting requirements from PRDs and recordings into clear flows
-
Where documentation was incomplete, I flagged the gap and validated it with stakeholders instead of assuming
Discovery & Constraints
Research combined existing PRDs, recorded stakeholder sessions, and direct conversations — no formal research had been run on this workflow before.
Privacy / Review team
-
Limited bandwidth to review requests regularly
-
Could flag miscategorized trackers, not block a technology outright
-
Large volume of first-party cookies with no documented purpose
Request raisers
-
Cross-functional: marketing ops, engineering, other roles company-wide
-
Requests came in inconsistent formats from multiple BUs
-
No visibility into status after submission
Personas
Request Raiser
Submits requests; needs simple flow + status transparency
Privacy Officer
Final compliance review, approve / reject
Data Steward
Validates data attributes & handling
Domain Owner
Reviews categorization within their product
Mapping the Tracker Lifecycle
Steps 8–9 were the biggest design opportunity: the original process had no way to catch trackers going live outside the request flow, or hold anyone accountable after approval.
Before vs. After
Before — Manual
-
Requests via email / forms / Slack
-
No status visibility
-
No cross-system consistency check
-
Compliance issues found reactively, if at all
After — [Product Name]
-
Single structured request flow
-
Live status + activity log
-
Automated drift detection across systems
-
Proactive remediation with ownership & due dates
The Solution
1. Request submission
A structured, guided form replacing free-form emails/spreadsheets — capturing tracker type, ownership, data attributes, geographic scope, and purpose, with a visible activity log.
2. Review queues by role
"My Requests" and "All Requests" views let reviewers triage pending work vs. monitor everything in flight, with inline Approve / Send Back actions.
3. Central tracker registry
A searchable system of record for every active tracker and tag, replacing disconnected spreadsheets with one source of truth.
4. Governance dashboard
The highest-leverage screen: a live health score across every tracker, breaking down why trackers are unresolved, with automated remediation tracking.
5. At a glance: system states
State
On track
At risk
Overdue
Meaning
Within SLA, no issues
Approaching due datePast due, escalated
Owner action
None
Review before deadline
Immediate remediation
✨ AI-Assisted Review (Phase 2 design concept)
With the registry and lifecycle in place, the Privacy Officer's biggest remaining cost was repetitive first-pass review: reading each request, checking the category, spotting duplicates, and writing send-back comments. I designed an AI assistance layer for this, built on the company's internal GenAI platform, with one rule: AI suggests, the Privacy Officer decides.
1. Request summary and risk flags
Turns a long request into a short brief and highlights risk signals (EU/UK data, session recording, identifiers collected).
3. Duplicate and similar tracker detection
Flags requests that resemble existing trackers so reviewers can reuse earlier decisions.
2. Category suggestion
Suggests a tracker category from the vendor, purpose, and data attributes, with a confidence score and the reasoning shown.
4. Drift triage and owner suggestion
Ranks unresolved trackers by risk and proposes the likely owner for ones with missing or mismatched owners.
Manual vs. AI-assisted
Task
First-pass read of a request
Categorization check
Duplicate check
Send-back comments
Remediation prioritization
Today (manual)
Read every field
Look up and compare
Search the registry
Write from scratch
Sort by hand
With AI assistance
Reads the AI brief and risk flags
Reviews the suggested category
Sees similar trackers inline
Edits a drafted comment
Risk-ranked queue
With AI assist
Confirms
Accepts or overrides
Decides
Edits and sends
Reassigns
Design principles for trust
-
Human in the loop: AI never approves or rejects. Every decision stays with the reviewer.
-
Explainable: each suggestion shows confidence and the fields it was based on.
-
Auditable: accept, edit, and override actions are written to the activity log.
-
Feedback loop: overrides feed back in to improve suggestions over time.
Target outcomes (hypotheses to validate in a pilot, not results)
30–40%
Target reduction in first-pass review time
>80%
Target suggestion acceptance rate
↓
Fewer send-backs from miscategorization
100%
Decisions made by a human
Interactive Prototype
Prototype yet to be added here
💡Key Design Decisions
-
Governance over intake: Shifted scope from "a form to submit requests" to a full lifecycle system with automated drift detection.
-
Role-scoped views over one generic table: Each suggestion shows confidence and the fields it was based on.
-
Designing for ambiguity: Where requirements conflicted, I proposed a resolution, flagged the assumption, and routed it for validation instead of guessing silently.
📈 Impact
Benchmarked against industry data for comparable workflow-automation systems — to be replaced with real numbers post-launch.
Target outcomes (hypotheses to validate in a pilot, not results)
~55%
Faster approval cycle
~50%
Fewer data discrepancies
~35%
Faster compliance visibility
87%
Tracker resolution rate*
*From governance baseline established at design handoff (2,614 of 3,000 trackers resolved).
🌱Learnings
-
The real product wasn't a request form — it was an accountability system. That reframe came from mapping the full lifecycle, not just the happy path.
-
Designing against incomplete or contradictory documentation is normal at the senior level; the job is surfacing and resolving ambiguity, not hiding it.