Before the Payouts tab existed, developers had no in-product visibility into their earnings.
I designed a developer-facing payouts dashboard with two views: an overview showing total collections, billing fees, and expected payout amounts, and a transactions tab with search and filtering for historical data. Later, I also integrated a self-serve refund flow directly within the dashboard, giving developers financial transparency and control without routing anything through support.
What I Did
- Defined the information architecture for the payouts dashboard (overview and transactions views)
- Designed the payouts overview showing total collections, billing fees, and expected payout amounts
- Designed the transactions tab with filtering and search for historical payout data
- Integrated a self-serve refund flow directly within the payout dashboard
- Worked with engineers and PMs to align design with backend payout infrastructure
Impact
- Actively used since early 2021, with a consistent and growing number of unique developers viewing their payouts data each month
- Eliminated the need to contact support for earnings visibility: expected payouts, billing fees, transaction history, and refunds all moved in-product
- The self-serve refund flow gave developers direct control over a high-stakes, previously support-routed action
Bottom line
Financial transparency is one of those things that should feel completely unremarkable to the person using it.
Getting the information architecture right here mattered more than any individual screen, because a developer who misunderstands their payout data can make genuinely bad business decisions based on it.