Redesigning transactions to help users understand their balances
Brief
V1 transactions shipped in December and missed the primary user need: to make sense of their balance. When V2 wasn’t progressing, it was reassigned to me.
Goals
Help users understand their balances
Retain customers by building a trustworthy, reliable app
Reduce support tickets on deposits, fees, and balances
Role
Lead product and content designer, collaborating with my PM, junior PM, and 2 engineers.
What a haunting Slack message. V1 transactions shipped quietly under my colleague’s direction in December, my second month at Lendtable. So quietly that I didn’t hear it over the rushing sounds of meeting people, learning the product, and starting my own projects.
In January, our manager sent that message: the transactions screen missed the point, which was to help users understand their balances.
Problem: V1 didn’t add up, literally
What’s in a balance?
At Lendtable, our users have a line of credit specifically to reimburse contributions to max their 401(k) match and ESPP benefits. Their balance (what they pay back) consists of what we reimbursed, a monthly fee to use the product, and a profit-share fee.
What did(n’t) V1 show?
V1 listed the reimbursement (gross deposit) and monthly fee (membership fee); together, these become the deposit that lands in a user’s bank account. It didn’t show the profit-share fee, or details on how fees and deposits are calculated. Users could not look at the numbers here and understand how that transaction or their total balance was determined. A constraint I’m still fighting is that a running balance isn’t shown on the transactions screen (more on that later).
GOAL: to reduce support needs and increase retention, transactions will allow users to understand the math behind their balances
Our support team regularly heard from upset and confused users after they got their first deposit: how did Lendtable get from my contribution to that number?
CHALLENGES: limited real estate, multiple fee types, complex math, and an unusual use case
About 90% of our users are on mobile. How can I create rows and columns that make sense and let the data breathe?
How do I distinguish a regular monthly fee from a profit-sharing fee?
How much detail should I include?
How is this similar to and different from credit/debit transactions? What design patterns should(n’t) I leverage?
Iteration
(1 of 6) My junior colleague's exploration of V2. The type hierarchy, groupings, and amount of information weren't progressing in the right direction after 3 weeks of feedback loops. A piece of feedback I return to time and again is for them to figure out what's vital for the UX before diving into high fidelity.
(2 of 6) My early lo fi explorations, showing the progression from including balances to the team decision to remove them, which allowed transactions to get the user's full attention and most of the viewport as well. The annotations list out what data types we can include as well as the difference between design options.
(3 of 6) A design review tool I often use is a side by side of the last iteration they saw and the latest. This brings people up to speed quickly and helps the meeting be more focused and productive.
(4 of 6) Type and color explorations. With color in particular, I want to make sure it's doing a specific job rather than doing too much, too little, or the wrong thing.
(5 of 6) The final design of our most complex use case: a use with both 401(k) and ESPP contributions over the limit set by their company policy.
(6 of 6) All receipt types by use case.
Solution: clear deposits, fees, and detailed receipts
What were the major changes to transactions V2?
Simplified color and type to match the neutral tone of reviewing transactions that all add up
Included monthly fees and the profit-share fees so the main components of a user’s balance were immediately visible
Provided receipts so users could drill down for more info
Why no negative or red numbers?
I understand my colleague leveraged these traditional banking fee signifiers in V1, but we needed to show how everything added up. Since monthly fees and profit-sharing fees aren’t being subtracted from their balance and it wasn’t anything that needed urgent attention or action, I used neutral colors within our design system.
Why treat monthly and profit-share fees differently?
The regular monthly fee is deducted from the first reimbursement of every month whereas the profit-share fee is a percentage of the after tax match or ESPP gain. By noting them separately, the math flowed down their receipts from contribution to deposit or fee more easily.
Why receipts?
Any way you slice it, the math is complex. I kept the transactions screen concise: deposits and fees are the numbers that add up to the total balance. Progressive disclosure of transaction details in the receipts allow users to understand exactly how we arrive at each number without overwhelming them on the transactions screen.
What would I have done differently?
Projects and sizing appropriate to level
Initially, V2 was assigned to my junior colleague that had handled V1. They’d designed everything at our startup for 3 years prior to me joining. A heroic effort for sure, but it was clear that they hadn’t had the time or guidance to develop design thinking, leadership, and dogged attention to detail necessary for a project of this scope. I wish I could get in my time machine and show them how to approach a project like this from the start, divide the work into appropriate size bites, and keep the feedback loops tight.
V3: running balance, CSV download, benefit money
When I pitched engineering and product on adding the new balance after each transaction and the total balance to the screen, I was met with resistance. Complexity, cost, blurring of screen intentions—many reasons tumbled forth and I wasn’t going to die on this hill, or at least not that day. It was more important that the experience progressed to better meet user needs.
For V3, I’m resurfacing incorporating balances, considering a CSV download, and visualizing how we might show how Lendtable increases dollars in 401(k)s and ESPPs.