When data quality fails silently, the business pays loudly
Banks run on data. But the tools used to govern that data were built for engineers - leaving compliance officers, data custodians, and business owners unable to author, validate, or act on data quality rules without IT involvement. I designed an enterprise Data Quality Management platform to change that.
METRICS
RULE CREATION TIME
40%
Custodians now author rules without waiting for IT tickets
APPROVAL WORKFLOW
60%
Faster rule approval cycle — email replaced with in-system workflow
VALIDATION & RESULTS
75%
Reduction in failures - validation moved before submission, not after deployment
TIMELINE
13 mo
Discovery to ship
ROLE
Product Designer - Discovery through launch
FOCUS
Rule authoring, validation, results, workflows
USERS
Custodians, Owners, Compliance, Executives
TEAM
1 Director, 1 Researcher, 2 PMs, 6 Engineers
My Contributions:
-
Redesigned the end‑to‑end rule authoring experience with a dual‑mode interface (templates + SQL editor) and live pre‑submission validation.
-
Created a unified, role‑based results system with RAG severity, actionable failure states, and four role‑appropriate lenses.
-
Designed the rule lifecycle and approval workflow, including the risk‑tier model balancing speed for Custodians with governance for Compliance.
-
Established the in‑system audit trail with timestamped, attributed state changes that replaced manual spreadsheet reconciliation.
-
Aligned four competing stakeholder groups (Custodians, Owners, Compliance, Executives) through systems‑level design decisions rather than escalation.
BEFORE & AFTER
PROJECT TIMELINE
13 months, discovery to validated post launch results
CUSTOMER PROBLEM
Data quality was a black box - for everyone who mattered
Rule creation takes too much time
Rule authoring was exclusively handled by engineering - every change, every new rule, every update required a ticket and a queue
No workflow
There was no formal approval process - rules went live without business owner review or compliance sign-off
Silent Failures
When rules failed, the only signal was a raw error log in a database table - invisible to the people responsible for acting on it
No Audit Trail
Compliance officers had no way to trace who authored a rule, when it changed, or what the historical results were
In banking, data quality isn't a technical concern - it's a regulatory one. The tools governing data quality were exclusively technical: raw SQL editors, error log tables, and command-line validation scripts that only engineers could operate.
Business users who owned the data were accountable for its accuracy had no visibility into whether rules were passing or failing until something broke downstream. Compliance officers received exported spreadsheets. Executive leadership saw nothing in real time.
HOW MIGHT WE
How might we give technical users full control over authoring and modifying data quality rules - while enabling non‑technical users to review, approve, and act on them without needing SQL?
This question surfaced from early discovery. The problem wasn't that rules couldn't be written - engineers were writing them. The problem was that the people who understood the business meaning of those rules had no way to author, validate, or act on them. The design had to serve four fundamentally different mental models simultaneously.
USER RESEARCH
Four roles. Four completely different definitions of "done."
Discovery interviews across all four roles revealed not just different workflows but fundamentally different mental models of what data quality governance meant. Designing one product that served all four required understanding each role on its own terms before attempting any synthesis.
Key research insight:
Every role used the word "trust" - but meant something different. Custodians wanted to trust their rules were running correctly. Owners wanted to trust results were business-meaningful. Compliance wanted to trust the audit trail was complete. Executives wanted to trust the dashboard wasn't hiding problems. The design had to earn trust differently for each audience.
Data Custodian
Owns day-to-day management of specific data domains. Needs to author rules, run validations, and monitor results without engineering support.
Blocked by IT queue
Data Owner
Accountable for data accuracy across a business domain. Needs to review proposals, approve changes, and understand results in business terms.
Invisible until something breaks
Compliance Officer
Responsible for regulatory reporting and audit readiness. Needs a complete, timestamped audit trail of every rule.
Manual spreadsheet reconciliation
Executive Leadership
Needs a real-time, high-level view of data health across the organisation - RAG status, trend lines, exception counts.
No real-time visibility at all
JOURNEY MAPPING
From four isolated workflows to one connected system
Mapping the as-is workflow per role showed all four operating in complete isolation — each doing their part with no shared system connecting them. A failure a Custodian knew about in week one could still be invisible to Compliance in week four.
The gap wasn't capability - it was connection. Each role had the knowledge to act on data quality failures. But there was no shared system connecting their workflows. A failure that a Data Custodian knew about in week one could still be invisible to a Compliance Officer in week four.
FEATURE DESIGNS
Three systems. One connected experience.
The design addressed the problem in three interconnected modules - each solving a distinct failure in the as-is workflow, but designed to share data, vocabulary, and workflow state so all four roles operated from a single source of truth.
01 - Rule authoring & validation - DATA CUSTODIAN
The authoring flow lets both technical and non‑technical users create rules in one interface: a guided builder for Custodians, and a template for advanced users.
Validation happens before deployment, with live data checks for compatibility, row counts, RAG status, and runtime.
Every rule enters a workflow (Draft → Review → Active) and requires the right approvals before going live.
02 - Rule results & failure surfacing - ALL ROLES
Failures were invisible in the old system, buried in database tables. The redesign introduced a RAG dashboard that made rule health instantly clear and tied severity to business impact. Each failure showed what broke, how serious it was, and the next action. Views were role‑specific - same data, different depth.
03 - Role-based approval workflow - CROSS-ROLE
The workflow replaced an informal email-based process with a traceable rule lifecycle. Custodians authored rules, Owners reviewed them, Compliance signed off when needed, and the system promoted them to Active. Each role saw only its relevant actions, and every state change was timestamped to create a complete in‑system audit trail.
RULE LIFECYCLE MANAGMENT FLOW
Wireframes
Rule authoring & validation. Users can create, edit rule from this screen. There are 4 types of rule behavior; Standard, Point-to-point, Variance checks and Variance Distribution Checks.
DQ Rules: Master rule list page with active and saved filters for users to display based on filter preferences.
Rule authoring & validation. Users can create, edit rule from this screen. There are 4 types of rule behavior; Standard, Point-to-point, Variance checks and Variance Distribution Checks.
USABILITY TESTING & ITERATIONS
12 participants, all four roles - one finding changed the design
Unmoderated, task-based study measuring task success rate, time-to-complete, and trust in results — 4 Data Custodians, 4 Data Owners, 2 Compliance Officers, 2 Executive Leaders.
80%
Task success across all four roles, without assistance
3 - 4 mins
To author a rule - technically-fluent Custodians
10–12 min
To author a rule - non-technical Custodians, nearly 3x longer
3.4/5
Average trust-in-results rating across all 12 participants
Custodians
Split result — technical users fast, non-technical users nearly 3x slower
Owners
Approved rules easily, no friction reported
Compliance
Viewed and understood audit reports without guidance
Executive
Assessed org-wide data health at a glance
The finding:
80% success looked strong in aggregate, but it masked a split inside one role. Non-technical Custodians, the exact audience the guided builder was built for, still got dropped into inline SQL validation the template library didn't cover. The no-SQL promise held for authoring; it broke down at validation.
The fix:
The template library was extended to cover validation, not just authoring - closing the exact gap where non-technical Custodians had been forced into SQL. This is what moved the project from usability study into UAT.
KEY DESIGN DECISIONS
Four decisions that shaped the system
01 - One interface, two modes - not two interfaces
A library of pre-built rule templates helps non technical users to create rules by selecting a template and configuring parameters in a guided form, with no coding required. Technical users retained a SQL editor with inline validation and schema-aware autocomplete for custom logic outside the template library; both paths shared the same interface, same validation and workflow engine.
One surface, two entry points
Challenge - SQL vs. no-SQL authoring
Iteration: usability testing showed the guided path still required SQL at validation, adding 3x the completion time for non-technical Custodians. The template library was extended to cover validation as well as authoring, closing that gap before moving into UAT.
FEATURE DESIGNS (CONCEPTUAL)
Three systems. One connected experience.
The design addressed the problem in three interconnected modules - each solving a distinct failure in the workflow, but designed to share data, vocabulary, and workflow state so all four roles operated from a single source of truth.
Challenge - Results visibility by role
02 - Same data, different depth - not different data
Rather than building separate dashboards for each role, I designed a single results system with role-scoped views. The data is identical - the depth is role-appropriate.
Role scoped view - single source of truth
Challenge - Failure states driving action
03 - Every Red result has a next step - no dead ends
Early designs showed failures as status indicators - visibility without action. Every failure state was redesigned to answer what failed, how serious it is, and what to do right now.
Visibility + action - not visibility alone
Challenge - Audit trail for compliance
04 - Every state change timestamped - in-system, not exported
Compliance Officers had been manually reconciling exported spreadsheets. The audit trail became a first-class feature — recorded in-system with timestamp and attribution.
In-system audit trail, no exports
RESULTS - POST LAUNCH - 3 MONTHS
What changed once the redesign shipped to users
40%
Rule creation time
Custodians author rules without waiting on IT tickets
60%
Approval cycle time
Email approvals replaced with in-system workflow
30 min
Audit prep time
Down from 2–3 weeks, via full in-system audit trail
75%
Post-deploy failures
Validation moved before submission, not after deployment
NEXT STEPS
Where the platform goes from here
Three initiatives are next in line, each building directly on what the usability study and UAT surfaced rather than starting from a blank slate.
More rule templates
Expand the template library beyond the initial set to cover additional common patterns - format/pattern matching, freshness checks, and cross-field consistency - so more rule types move out of the SQL editor and into the guided, no-code path.
Rules under a minute
Push average rule creation time below 60 seconds for the most common rule types - building on the 40% reduction already validated - by pre-populating templates from historical rule patterns per domain.
AI-assisted rule authoring
Explore natural-language rule creation: a Custodian describes intent - "flag missing addresses over 2%"- and the system drafts a matching rule for review, reducing the guided builder's remaining learning curve.
Push rule
Let a Custodian propagate a validated rule across related domains or datasets in one action, instead of authoring the same rule from scratch per domain - extending the "author once" principle beyond a single rule instance.
WHAT I LEARNED
Three principles this project embedded in how I work
Role-based design is not persona-based design
Personas describe who someone is. Roles describe what they're permitted and expected to do. In enterprise systems, the role is the design constraint — not the person. Designing for roles first prevented the feature bloat that comes from trying to satisfy everyone on every screen.
The audit trail is a product feature, not a compliance afterthought
Compliance Officers spend significant time reconstructing histories that a well-designed system would have recorded automatically. Treating the audit trail as a first-class design surface — not a database dump — turned a painful quarterly process into a filtered view.
Competing stakeholder needs are a design problem, not a politics problem
When Data Custodians and Compliance Officers wanted opposite things from the workflow, the instinct is to escalate to leadership. The better move is to reframe the conflict as a design problem — find the constraint (risk tier) that satisfies both without requiring either to lose. That's what the risk-tier approval model did.