Case Study 02 · Regulatory Audit Design

Compliance
Monitoring
Dashboard

Compliance officers can't tell what the AI touched — and regulators are asking. This is the design process behind an audit interface that makes AI-generated actions legible, attributable, and reviewable without technical knowledge.

Compliance UX Financial Services Dense Data Tables Role-Based Views Audit Trail Design

ROLELead / Solo Designer

SCOPEProduct + data visualization

USERSCompliance Officers, Engineers

REGULATORYSEC / FINRA audit readiness

TIMELINE5 weeks discovery → prototype

Phase 01 — Discovery

What regulators actually ask

Before designing a single screen, I spent two weeks studying SEC and FINRA audit questionnaires and interviewing two compliance officers. The finding was striking: existing tools answer none of the three questions regulators actually ask.

The Three Regulator Questions

SEC and FINRA examiners consistently ask three things when reviewing data platform activity. I designed the entire information architecture to answer these three questions — before any other feature.

REGULATORY REQUIREMENTS ANALYSIS

Q1: "What changed in your data, and who authorized it?"
   → Requires: full actor attribution (human vs system vs AI), change detail, approval chain

Q2: "How did your AI system affect the data record?"
   → Requires: AI actions labeled distinctly, confidence at time of execution, human override status

Q3: "Show me everything that touched this record."
   → Requires: record-level drill-down, full event timeline, exportable for counsel

FINDING Existing tools answered Q1 partially. Q2 and Q3 were unsupported entirely.

Persona Analysis — The Two Users Who Must Co-Exist

This dashboard serves two fundamentally different users in the same interface. I mapped their distinct needs, time pressures, and technical comfort levels to ensure neither user sacrifices their core requirement.

DUAL PERSONA MAP

DIMENSION	COMPLIANCE OFFICER	DATA ENGINEER
Primary goal	Prove nothing improper happened to a regulator	Find and fix the pipeline error causing data drift
Time pressure	Exam notice: 48 hours to produce records	Production is failing: fix in the next 30 minutes
Technical comfort	Low — understands business logic, not schema	High — reads SQL, understands schema and data types
Key interaction	Filter → read → export PDF for counsel	Filter by error → drill into schema detail → fix source
Design requirement	Plain language, no jargon, one-click export	Full technical detail available on demand, not hidden

Phase 02 — Information Architecture

Structuring the event hierarchy

Event Taxonomy — Defining What Gets Logged

Before any UI decisions, I defined the complete event taxonomy: what categories of events exist, which actors can generate them, and how they relate to each other. This taxonomy became the foundation of the filter system.

EVENT TAXONOMY

EVENT TYPE	ACTORS	VISUAL TREATMENT	DEFAULT SORT PRIORITY
Schema Exception	system	CRITICAL · red left border	Always first
AI Action	ai-agent	AI ACTION · purple label	Second — needs review
Human Edit	named user	MODIFIED · amber	Third
System Event	system / scheduler	SUCCESS · green	Last — lowest risk

KPI Architecture — The Four Numbers That Matter

I selected exactly four KPI metrics after testing seven candidates with compliance officers. The rule: each KPI must directly answer a question a regulator asks. Decorative metrics were cut entirely.

KPI SELECTION RATIONALE

KEPT: Total Events → "What was the volume of activity?"
KEPT: AI Actions (% of total) → "How much of this was automated?" REGULATOR KEY
KEPT: Flagged for Review → "What's outstanding / unresolved?"
KEPT: Schema Exceptions → "What failed and might need disclosure?" HIGH RISK

CUT: Avg. processing time → engineering metric, not compliance
CUT: Records per pipeline → too granular, distracts from risk
CUT: User login count → security metric, different report

Phase 03 — Design System

Light, authoritative, readable

Aesthetic Direction — Why Light and Neutral

Compliance dashboards are read under pressure, often in formal settings and shared with legal counsel. I chose a warm-neutral light palette (warm white, parchment background) that reads as authoritative and document-like rather than "tech product." The navy header creates institutional gravitas. Nothing is decorative.

COLOR SYSTEM · SEMANTIC PALETTE

Navy
Header / Authority

Teal
Success / Verified

Gold
Warning / Review

Crimson
Critical / Error

Purple
AI-Generated Action

Parchment
Document surface

Table Design — The Central Challenge

Data tables in compliance tools must balance density (show as many events as possible without scrolling) with scannability (the compliance officer must be able to identify critical items in under 5 seconds). I iterated through 4 row height variants and 3 column orderings before the final design.

COLUMN ORDER RATIONALE

V1: [Timestamp · Integration · Actor · Event · Status · Records] — REJECTED
Problem: Integration and Actor before Event buries the most important column

V2: [Timestamp · Status · Actor · Event · Integration · Records] — PARTIAL
Problem: Status chip before Event description forces eye to jump

V3 (FINAL): [Timestamp · Event · Integration · Actor · Status · Records]
RATIONALE Timestamp anchors time → Event describes what happened → Integration says where → Actor says who → Status is the verdict → Records is a data point

Phase 04 — Working Interactive Prototype

The full compliance dashboard

Fully interactive. Filter by event type, click any row to expand the detail panel, sort columns, switch time periods, and generate an audit report. Try clicking a CRITICAL or AI ACTION row first.

Phase 05 — Reflection

What this design gets right

Critical Design Decisions

DECISION 1 ai-agent is a named actor, distinct from system and human
DECISION 2 Critical rows get left-border accent, not just a chip
DECISION 3 KPI cards are clickable — they filter the table below
DECISION 4 Expandable row detail without leaving the page
DECISION 5 "Generate Audit Report" is the primary CTA — not "Export"

Next Iterations