Company
Ramp Network
Industry
Crypto fintech
Transaction Status Page
Transparency as value proposition
Users didn't know what was happening with their transactions. The only feedback was "success" or "failure" — no stages, no reasons, no timeline. Support tickets were dominated by a single question: "Where is my money?" I initiated and led the creation of a comprehensive transaction status system that mapped three interdependent layers (frontend, backend, compliance) into a human-readable timeline. The result: 47% reduction in support tickets and 34% improvement in conversion, driven by user trust and transparency.
Context & Problem
Before this project, a user who bought Bitcoin through Ramp Network would see their transaction as either complete or failed. There was no visibility into the stages between: compliance checks, payment processing, secondary compliance verification, treasury allocation, and blockchain delivery. Each of these stages could introduce delays — payment providers don't process on weekends, Bitcoin confirmations can take hours, compliance reviews may require additional documentation. The result was predictable: users panicked. Their money had left their bank account but crypto hadn't arrived. They couldn't see why. Support was flooded. But the problem wasn't just user-facing. Internally, the event logs were unreadable. Product managers couldn't diagnose where transactions were failing without engineering help. The lack of a structured status system was a blind spot across the entire organization.
Strategy
This project significantly exceeded the scope of a designer's typical remit. I initiated it because I was personally frustrated by the same opacity our users experienced. To design the status system, I first had to understand the complete transaction pipeline — which meant mapping dependencies across three layers: Frontend layer: What the user sees and can act on Backend layer: Payment processing, treasury management, crypto delivery Compliance layer: Risk assessment, KYC checks, jurisdiction rules, fraud signals These three layers are interdependent and interleaved. Sometimes the frontend waits on the backend. Sometimes the backend waits on compliance. Sometimes compliance triggers after payment and requires additional user action. I had to map all of this before I could design a single status message.
Understand the transaction creation
Here's what actually happens when a user buys crypto (on-ramp), simplified but accurate:
Transaction created — User requests to buy a specific asset for a specific amount, to a specific wallet, using a specific payment method.
First compliance check — System evaluates whether the transaction can proceed: wallet screening, payment method validation, risk scoring, jurisdiction rules. External risk-assessment tools provide verdicts.
Payment execution — If cleared, the payment provider collects funds from the user. Different providers have different behaviors, speeds, and failure modes.
Second compliance check — After payment, additional information is available about the user. A second evaluation determines whether delivery can proceed.
Treasury allocation — System checks whether sufficient crypto is available in Ramp's vault. In extreme market conditions, liquidity gaps can cause delays while the treasury team replenishes.
Crypto delivery — Funds are sent on-chain. The user waits for blockchain confirmations, which are entirely outside Ramp's control and vary by network (seconds for some chains, hours for Bitcoin).
Completion — Crypto arrives in the user's wallet.
At every stage, the transaction can fail, expire (if the user doesn't act), or require additional compliance actions. For off-ramp, there's an additional refund flow when users send incorrect amounts.
Transparency & Conditional Messaging
I adopted a transparency principle inspired by blockchain itself: if the system is transparent, users can see what happened without needing to interpret jargon. Every status message is written in plain language, with no blame attribution — neither the user nor the system is positioned as "at fault" when things go wrong.
Statuses update dynamically. I designed conditional messaging that adapts to the specific scenario — a payment-provider delay on a weekend gets different copy than a compliance hold or a blockchain congestion delay. The goal was always to give the user the sense that everything is under control and nothing has frozen.
Research & Deprioritized Scope
I used AI-assisted analysis of support ticket summaries to identify the most common confusion points, rage-click analysis in Hotjar to see where users were desperately seeking more information, and user interviews (conducted after I had a working concept for all status categories, not before — the quantitative data shaped the design direction, interviews validated it). Deeper blockchain confirmation mapping was deprioritized — showing users exactly how many confirmations had occurred and how many were needed would have been valuable but fell outside scope. I also wish the payment method failure messaging was smarter — ideally, when one method fails, the system would suggest alternatives ranked by historical conversion data. That intelligence layer didn't make it in.
Impact
Support tickets reduced by 47% (measured in Intercom)
Conversion improved by 34% (measured in Amplitude) — transparency increased trust, which increased completion rates and return usage
Partners reported positive downstream effects on retention
InInternal product team gained visibility into transaction pipeline for the first time — Product Teams began diagnosing issues independently using the same status framework
Tradeoffs & Reflection
This project taught me that the most impactful design work sometimes starts with understanding systems you weren't asked to understand. If I'd waited for a brief that said "design a transaction status page," it wouldn't have happened. The initiative came from personal frustration and a belief that transparency is always better than opacity — a principle I'd carry directly into cross-chain transaction design.
Testomonial
"In over three years of working with Michał at Ramp Network, he stood out as one of the most data-engaged people in the entire org — and I say that as someone who led the Data team. He tracks adoption, asks the right questions, and genuinely cares about what happens after a product feature ships. His designs look sharp and work intuitively — a balance most designers talk about but few actually deliver. Hire him."
