Work / Ownera (fintech, backed by J.P. Morgan) · 2023 → 2026
From JSON Dump to Transaction Lifecycle
-
Ownership
Sole designer
-
Scope
The platform's most-used screen
-
Sector
Fintech · Institutional
-
Shift
CS escalations → self-serve diagnosis
TL;DR
Problem → The admin's most-used screen showed transactions as raw JSON trees. Every stuck transfer became a Customer Success escalation.
What I did → Reframed the log from a data dump into a transaction lifecycle: a flow view for diagnosing one transaction, connected to a table view for monitoring many.
Result → The users closest to the pain, operations and CS, could read a stuck transaction at a glance instead of escalating it.
Context
Ownera is a fintech platform connecting banks and financial institutions to trade tokenized digital assets, backed by J.P. Morgan. I worked on its Admin Platform, where finance teams manage every transaction in the system; the Transaction Log was its most-used screen, lived in daily by the clients' operations teams and by Customer Success. I was the sole product designer, working directly with the Director of Product.
The Moment
A banker gets a call: a client's expected transfer never arrived. They open the transaction log to check, and hit a wall of raw JSON. The information is all there, including why it's stuck, but nothing is readable. So they do what everyone did: forward it to Customer Success to decode. Every incident became an escalation, and in a platform sold to financial institutions, a core screen that looks like a developer console is a risk in every demo.
The Decisions
01A lifecycle, not a tree
The assumption was that users needed more data and more filters. Watching operations people work showed the opposite: they arrive already knowing which transaction they need, search by ID, and want context, what happened, where it stopped, what to do next. The JSON already contained a full process: stages, organizations, statuses. So I didn't invent a new model, I gave the existing one the representation it deserved: each transaction as a left-to-right flow, with the failure marked at the exact stage it occurred. Same data, shown as the process it always was.
02Two views, not one
Diagnosing one transaction and monitoring hundreds are different jobs. I split the screen into a full-screen flow for depth and a table for scale, and accepted the context switch on purpose: one view doing both jobs does neither well.
03What I rejected: inline expansion
Inline expand/collapse inside the table, essentially what the old screen did, was the safe choice. But real usage showed no scenario where users compare several transactions side by side; they focus on one. So each transaction got a screen of its own.
What Changed
Operations teams and CS read failed transactions without escalating. We didn't set up formal measurement; my instrument was CS themselves, when they stopped needing to decode, it worked. Next time, I'd define one lightweight signal upfront: how long it takes to explain a failed transaction, before and after. The work was presented and approved up to the CTO, GM, and CEO.
Next Project