2019 – 2021 · Azure Purview

Project Babylon —
Azure Purview Launch

Azure Purview · Data Governance & Policy · Launch Dec 2020

Zero-to-one Lead Design (Policy UX) Scenario Design Platform Strategy Data Governance

Shipped Azure Purview policy builder for a Restricted Access encryption policy, with the Effect dropdown open showing Allow and Deny options

TL;DR

The Azure Purview policy builder was a zero-to-one problem: no product yet, no established pattern for pairing data cataloging with active policy enforcement, and a small founding team figuring out what “govern your data” should even look like.

I led policy management and compliance UX. The people who'd own these policies understood their data deeply but weren't legal specialists, so ensuring clarity was the main design challenge.

I built a guided policy builder that reads like a sentence, made from constrained choices instead of free text, so a policy could be authored correctly and understood at a glance. Labels went through several rounds of user-tested renaming before the language actually landed.

The feature launched to a strong reception — an estimated 23% increase in product engagement — and became the foundation the rest of Purview's compliance tooling was built on.

The Details

The Problem

As Azure Purview matured, cataloging alone stopped being enough. Users could finally find and understand their data estate — but they still had no easy way to act on what they found. The design challenge shifted from helping people see their data to helping them govern it, without requiring them to become data governance specialists to do so.

No single Microsoft product could yet answer questions like “Is our data use compliant with GDPR?”, “Who accessed sensitive data and what happened?”, or “How do we prevent improper data sharing?” — and no established UX pattern existed for a platform that combined cataloging with active policy enforcement. Project Babylon was the answer.

Journey diagram titled "Policy creation", tracing Gloria the DBA, Dorothy the Data Officer, Roger the Data Engineer and Ann the Data Analyst through connecting a server to Azure, cataloguing it, adding GDPR and HBI policies, and reviewing lineage and reports — One of many such transit diagrams, mapping Dorothy’s requirements/ painpoints and how they fit in the greater Purview context.

Research

The team started with a user deep dive with customers to understand key “Jobs to Be Done” narratives for our persona across Purview. Throughout our broader customer research, it quickly became clear these three pain points are the ones we absolutely need to solve for.

Data catalog governance is an overwhelming effort
Policy creation is high impact, with potentially big consequences
Our persona is already doing a lot; often 1 or a just a handful of people responsible.

Dorothy wears a lot of hats. She’s exhausted.

Insight

Our key persona the Data Officers were well versed in data; but they weren't legal specialists. Holding responsibility for GDPR or CCPA compliance is different from being trained in GDPR or CCPA itself. That gap — real governance ownership without regulatory expertise — is what made simplicity and comprehensibility non-negotiable. A data officer needed to be able to write a policy correctly, and see plainly what it would actually do, without needing a law degree to do either.

Azure's existing Policy definition form, where the policy rule is authored as raw JSON in a code editor beneath the name and category fields — An example of the technical focused policy building UX in Azure

Storyboard frame: Dorothy the Data Officer asks how to ensure data is GDPR compliant, and opens Babylon's Policy Manager to the GDPR policy group — Early storyboards/wireframes

Storyboard frame: the GDPR policy group screen, where a template reads "Create policy DataPrivacy As Deny Read On Highly_Confidential To non-admin_users" — Early storyboards/wireframes

Decisions

Rather than exposing the underlying technical config directly, I designed a guided policy builder that reads like a sentence — but is composed from structured, guided selections, not free text. “Take this Effect for this Action on these Data Resources to these Subjects” — every word a discrete, constrained choice, so a policy could be authored and understood at a glance without requiring engineering or legal training to get right.

The policy builder with an empty statement — "Take this Effect for this Action on these Data Resources to these Subjects" — each field a coloured dropdown

The same builder filled in — "Deny Read on data belonging to Finance to all except Core Finance Team"

Outcome

The broader focus throughout was precise, high-scrutiny content design: every label and word in the policy builder had to carry exact technical meaning while staying readable to someone who wasn't a specialist. One clear example of that bar in practice — the fields now labeled “Data Resources” and “Subjects” went through several rounds of renaming after user testing.

Wording that read as perfectly clear during design turned out to confuse real users, partly because the industry's own governance terminology was shifting at the time.

Shipped New policy screen in Azure Purview, with the policy builder sentence and a Tips panel showing an example policy statement

Impact

The compliance and policy narrative I designed was very well received, resulting in a significant product engagement increase, estimated around 23% (based on memory of internal telemetry metrics); it was the feature customers were waiting for. It eventually became the foundation Purview compliance functionality grew on — eventually evolving into the broader Microsoft Purview suite that now underpins the company's entire data security portfolio.

1 / 6

← Microsoft Priva – Privacy management

Project Babylon —Azure Purview Launch