Case Study 01 · AI-Native Financial Platform

AI Transformation
Builder

Business analysts need to build data transformations — but can't write SQL. This is the design process behind a natural language interface that makes AI output trustworthy enough for financial services.

AI Interaction Design Non-deterministic UX B2B / Enterprise Financial Services Data-Dense UI
ROLELead / Solo Designer
SCOPEEnd-to-end product design
USERSBusiness Analysts, Data Engineers
TOOLSFigma, FigJam, HTML/CSS/JS
TIMELINE6 weeks discovery → prototype
Phase 01 — Discovery & Problem Definition

Understanding the real problem

Before any sketching, I conducted 8 user interviews across two personas: business analysts who need the tool and data engineers who currently own the process. The gap between them revealed the core design problem.

01
Stakeholder Interviews — Discovery Findings
Interviewed 4 business analysts and 4 data engineers at a mid-size asset management firm. Key insight: engineers didn't resist automation — they feared losing visibility into what changed and why. Business analysts didn't fear SQL — they feared being blamed for a bad transformation they couldn't audit.
INTERVIEW SYNTHESIS · VERBATIM QUOTES
"I can describe exactly what I need — I just can't write the code for it." — Sr. Analyst, FP&A
"If the AI changes something and it's wrong, who's accountable? Not the AI." — Lead Data Engineer
"I don't need to understand the SQL. I need to trust it." — Portfolio Analyst
"Every time I hand off a transformation ticket, I lose 2 weeks and context." — Business Ops

CORE TENSION Trust ≠ Understanding · Users need to trust output they can't fully evaluate
02
Problem Statement & Design Principles
From synthesis, I defined the core design problem and three non-negotiable principles that would govern every decision in this project.
DESIGN PRINCIPLES · RANKED
PRINCIPLEWHAT IT MEANS IN PRACTICEPRIORITY
Trust before speedNever auto-apply AI output. Every transformation must pass through a human decision point — accept, edit, or reject. Speed is secondary to confidence.Critical
Explainable uncertaintyConfidence scores alone are insufficient. Surface what the AI is uncertain about, not just how uncertain. "87%" means nothing. "Verify date cast on line 4" means something.Critical
Engineer trust, alwaysBusiness users operate the tool; engineers must be able to override, audit, and inspect anything the AI generated. The governance layer is never hidden.High
Phase 02 — User Flow Mapping

Mapping the critical paths

I mapped two flows: the happy path (AI gets it right) and the exception path (AI is wrong or uncertain). Both paths had to be first-class design concerns — not just the happy path.

03
Primary Flow — Business Analyst, Happy Path
The analyst enters a natural language prompt, the AI generates SQL, the analyst reviews with confidence signal and inline annotations, then accepts. The transformation runs and appears in the audit log.
FLOW DIAGRAM · HAPPY PATH
Analyst types promptNatural language
AI generates SQL+ confidence signal
User reviews outputAccept / Edit / Reject
Transform runsAudit log entry
EXCEPTION PATH — AI LOW CONFIDENCE
Analyst types prompt
AI output <70% conf.
Warning surfacedSpecific annotation
User edits SQLOr escalates to eng.
Runs w/ modified flag
04
Information Architecture — Sidebar Navigation
Before designing any screen, I mapped the full IA. The sidebar structure had to serve both the business user (simple, task-oriented) and the data engineer (complete, auditable). I chose a shared nav with progressive disclosure rather than role-switching — one surface, one mental model.
IA MAP · SIDEBAR STRUCTURE
NAV ITEMPRIMARY USERSECONDARY USERBADGE LOGIC
DashboardBusiness AnalystEngineerNone
SourcesEngineerAnalyst (read)Error count
TransformationsBusiness AnalystEngineerActive count
PipelinesEngineerAnalyst (read)Running count
Audit LogCompliance / Eng.Analyst (limited)Review-needed count
DestinationsEngineerAnalyst (read)None
Phase 03 — Design System Foundation

Tokens, type, color system

I built the token system before any components. The dark theme was chosen deliberately: engineers live in dark code editors. The business user was new to this environment — the design had to feel precise and capable, not intimidating. Every color encodes semantic meaning.

05
Color System — Semantic Palette
Each color maps to a specific meaning and is never used decoratively. Cyan = AI / system actions. Green = success / acceptance. Red = error / rejection. Amber = warning / needs review. Purple = AI-generated specifically. This consistency means users learn the system visually — no labels required at a glance.
COLOR TOKENS · SEMANTIC MAPPING
Cyan
#39c5cf · AI / System
Green
#3fb68e · Success / Accept
Red
#cf3939 · Error / Reject
Amber
#d4a84d · Warning / Review
Purple
#a882d4 · AI-Generated
Text Primary
#e6edf3 · Primary
06
Typography System — Three-Font Architecture
Display (Fraunces): editorial weight, for headings that communicate ambition and precision. UI (Syne): geometric, confident for product chrome and labels. Mono (JetBrains): the technical layer — code output, timestamps, IDs, system labels. Each font occupies a distinct semantic register — users feel the shift between each layer without consciously noticing it.
TYPE SPECIMENS
DISPLAY
Fraunces 100
Page headers
Marketing titles
AI Transformation
Builder
UI BODY
Syne 500
Product chrome
Labels, nav
Integration Monitor · Live Pipeline · Bloomberg Feed
MONO
JetBrains 400
Code output
Timestamps, IDs
SELECT t.fund_id, t.trade_date::DATE AS trade_date_iso
Phase 04 — Component Design & Hierarchy

The confidence signal — the critical component

The most important component in the entire product is the confidence signal. It's the bridge between AI capability and human trust. I iterated through 6 versions before landing on the final pattern: percentage + specific annotation + gradient fill encoding urgency.

07
Confidence Component — Iteration History
Every iteration failed until I separated "how confident" from "why uncertain." A number alone triggers either over-trust (91% sounds great) or under-trust (67% sounds bad). The annotation is the design — the number is just context.
ITERATION LOG
V1: Just a percentage badge · FAILED — no context, users dismissed it
V2: Percentage + color (green/amber/red) · FAILED — binary thinking, users ignored amber
V3: Progress bar only · FAILED — felt like a loading indicator
V4: Percentage + bar + generic "Review recommended" · PARTIAL — better, but vague
V5: Percentage + bar + specific line-level annotation · WINNER — users knew exactly what to check
V6 (final): V5 + gradient fill encoding confidence level in the bar itself
08
Visual Hierarchy — Screen Priority Map
I mapped every element on the main transformation screen to a hierarchy tier. Tier 1 elements get maximum visual weight; Tier 3 elements recede. This prevented the common enterprise failure mode: everything is equally visible, so nothing is actually visible.
HIERARCHY MAP · TRANSFORMATION BUILDER
TIERELEMENTVISUAL TREATMENTRATIONALE
T1 · PrimaryAI Output + Confidence SignalFull width, primary text color, gradient barThis is the moment of truth — nothing competes with it
T2 · SecondaryAccept / Edit / Reject actionsColor-coded, immediate below outputDecision follows output — spatial proximity = mental proximity
T3 · TertiaryVersion history, run count, timestampsMono text, muted color, bottom of screenAvailable on demand; should not compete for attention during generation
T4 · HiddenSchema details, column types, row countsTab-gated; only shown on requestEngineers need this; analysts shouldn't see it unless they ask
Phase 05 — Working Interactive Prototype

The full working interface

This is the production-fidelity prototype. Type a prompt in the field below and hit Generate — the system will simulate AI generation, display the SQL output with confidence scoring and inline annotations, and give you the full accept/edit/reject flow. Switch between tabs to see version history and diff view.

Nexus Platform · AI Transformation Builder · nexus.io/transformations/new
Dashboard
Sources
Transformations
3
Pipelines
Audit Log
2
Destinations
Settings
fx_rates → trades_normalized
bloomberg_feed  ·  Last run: 14:02:31  ·  4,821 records processed
● LIVE
1,204 runs
Run History ↗
▸ AI TRANSFORM PROMPT
Generated SQL
Version History
Diff View
Type a prompt above and hit Generate
to see AI-generated SQL with confidence scoring
14:02:31 today
Normalize trade_date to ISO 8601, join fund_id, filter USD
ai-generated
91%
13:44:02 today
Normalize trade_date — edited by j.chen before acceptance
j.chen · edited
87%
09:18:44 yesterday
Initial transformation — join trades to funds table
ai-generated
78%
t.trade_date AS trade_date, -- original untyped
+t.trade_date::DATE AS trade_date_iso, -- normalized, AI-suggested
t.amount,
t.currency,
FROM trades t
+FROM trades t
+JOIN funds f ON t.fund_id = f.id -- new join, AI-added
+WHERE t.currency = 'USD' -- new filter, from prompt
Phase 06 — Outcomes & Reflection

What the design actually solved

Key Design Decisions
DECISION 1 Confidence annotation is line-specific, not generic
DECISION 2 Accept/Edit/Reject always visible — never just "Apply"
DECISION 3 AI actor labeled separately in audit log from system/human
DECISION 4 Dark IDE theme signals "this is a precision tool"
DECISION 5 Version history is first-class — not buried in a menu
What I'd Explore Next
NEXT 1 Streaming output — animate SQL generation token by token
NEXT 2 Schema preview panel — show what fields exist before prompting
NEXT 3 Saved prompt library — reuse successful prompts across integrations
NEXT 4 Collaborative review — engineer can annotate AI output for analyst
NEXT 5 Mobile alert when AI-generated transform fails in production