Making data quality
accessible and scalable.

01 / The problem

When data quality breaks down,
decisions do too.

Business decisions and day-to-day operations depend on the data powering them. Incomplete, inconsistent, or stale data can produce misleading reports and carry errors into downstream workflows.

Business owners and data stewards need a way to:

1. Determine if their data meets the requirements for its intended use
2. Identify where it fell short
3. Triage quality issues before the data is used by others

Turning those expectations into repeatable quality checks is a process that requires a lot of technical expertise. Connecting to data sources, running data profiles, and coding quality checks meant business users had to rely on specialists, even when they understood the data and the standards it needed to meet. This created bottlenecks and limited the scope and scale of the data quality validations they were able to produce.

Streamlining that process became the design goal: help business users define and evaluate quality expectations, act on issues, and maintain visibility as the scope of their data grew without requiring deep programming or scripting expertise.

02 / The people

Separate the infrastructure
from the everyday work.

Managing infrastructure and deciding whether data meets a business need are different responsibilities. I made the business user the primary persona, with the data engineer or architect supporting the technical setup.

In stakeholder discussions, I used the analogy of a driver and a road construction worker. Both matter, but they need different experiences. Business users should be able to manage quality without having to build the road first.

03 / The decisions

Start with the validation.
Then select the data.

Should users select a column and apply multiple rules, or configure a rule and apply it to multiple columns? I initially explored letting users choose either path.

Testing showed that the rule-first approach was more intuitive and scalable. This led to the list of no-code out of the box quality checks that users could select and apply to their data. It gave them a concrete starting point for quality checks and allowed them to go from identifying target data to generating scores in a matter of minutes, something that would have taken upwards of an hour prior to this tool.

1. 01Choose a ruleWhat do I want to check?
2. 02Configure itWhat does good look like?
3. 03Apply to columnsWhere should it apply?

Enlarge image

An assessment needed its own identity.

The original direction placed DQ inside a tab on an existing data asset. I moved toward a standalone assessment linked to the asset, giving quality workflows room to grow and making assessments easier to manage across the estate.

It also addressed an important audit requirement: assessment history needed to remain accessible even if the source asset was removed.

04 / A different scale

The same intent.
A different platform model.

Bringing DQ into Microsoft Fabric required more than adapting the interface. Fabric's platform capabilities and technical audience changed how quality could be created, configured, and reported.

Creation now began with a bounding container and the tables it would include. Existing platform controls also let me simplify the DQ experience, surfacing configuration as context or directing users to established tools.

Enlarge image

05 / What shipped

From a technical capability
to an everyday practice.

Purview Data Quality shipped as part of Unified Catalog. The experience connects quality rules and assessments to a broader view of data products and governance domains.

The Fabric integration entered private preview shortly before my departure, with positive feedback from prototype usability testing with internal practitioners who used Fabric and Purview in their daily work.

The result was a foundation for managing quality at different scales: accessible, asset-level assessments in Purview and checks spanning multiple tables in Fabric.