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
10 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.
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
The product wasn't broken in one place - it was broken in four. And the four failures compounded each other: a rule that took days to create couldn't be validated before deploying, failed silently in production, surfaced to no one in a useful way, and required another lengthy change cycle to fix.
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.
The sharpest research insight
Every role used the word "trust" during interviews - but meant something entirely 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. One product had to earn four different kinds of trust simultaneously.
Data Custodian
Owns day-to-day management of specific data domains. Needs to author, test, and deploy rules without IT dependency.
Blocked by IT queue
Compliance Officer
Responsible for regulatory reporting. Needs a complete, timestamped, in-system audit trail of every rule and result.
Manual spreadsheet reconciliation
Data Owner
Accountable for data accuracy. Needs to review and approve rule changes in business terms — not raw SQL output.
Invisible until something breaks
Executive Leadership
Needs a real-time high-level view of data health — RAG status, trend lines, exceptions — without operational detail.
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.
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
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 - INITIAL TEST LAUNCH - 2 WEEKS
What changed once the redesign shipped to draft 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
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.