Rebuilding the Revenue Sheet

About the product

The Revenue Sheet is one of the most heavily used features by Wealth Advisors on the Wealthy Partner platform. It enables them to track earnings, commission breakdowns, and analyse income across multiple financial products.

That last part is what makes it hard. An advisor's income is not one number. It arrives as trail and upfront commission on mutual funds, revenue share on broking, commission on insurance at issuance and renewal, and placement fees on PMS, AIF and bonds, each on its own schedule, each locked or unlocked, with tax treatment layered on top. The old sheet showed all of it at once.

The redesign had two goals:

1. Redesign and streamline the existing web experience, to address usability issues and feature gaps.
2. Design and scale the Revenue Sheet for mobile, a first-time initiative to enable easier on-the-go access.

Team

Led in collaboration with a Product Manager who defined the roadmap and KPIs, and a fellow Product Designer who ran the user interviews. I worked on UX and UI, and on turning the interview findings into the design for both web and mobile.

How we did it: research and insights

We started with qualitative research through 13 structured user interviews. Partners were selected on frequency of use and availability, so the people in the room were the ones who opened this screen most.

Interviews ran as calls and scheduled Google Meets, with open-ended questions designed around current pain points and usage patterns rather than around the existing interface. The questions we asked:

• What details do you want from the Revenue Sheet?
• What do you find missing?
• How do you use it on desktop?
• Do you face technical or data issues?
• When and why do you refer to the Revenue Sheet?
• Which components are used most?
• Are any analytics or insights lacking?

The verdict was "dissatisfied"

The research opens by placing partners on a satisfaction scale, and the marker sits between Moderate and Frustrated. The headline on that page is blunt: Dissatisfied Users, Dealing with Data Overload in the Revenue Sheet.

Ten pain points came out of the interviews. The one that reframed the project was not about volume at all.

Data in the Revenue sheet is overwhelming to the users. Cannot interpret data easily. User is not sure if the data are valid or error free and they have no idea from where the data is coming from. Partners are spending a lot of time to reconcile and analyse the Revenue sheet.

That is not a density problem, it is a trust problem. A partner reconciling a figure by hand is not doing it because the table is long. They are doing it because they cannot tell whether the number is right, and the screen gives them nothing to check it against.

What the research said to do about it

The solution section of the board is mostly instructions to the designer, and they are specific enough to design from. The ones that shaped the most:

• Provide consolidated high-level information at the first level, low level info later. Repeated in several forms: expect smaller chunks of data at first level, and revenue first and rest of the info next.
• Put a trust mark or validation beside the data, and mention where the data is coming from. This is the answer to the trust finding above.
• An information icon on each figure, opening the detail of how it was calculated. Every headline number in the final design carries one.
• Show the download option at the second level, not at the beginning. Export stays available, but it stops being the obvious first move.
• Keep the payout sheet and the revenue sheet visually distinct, since conflating them was part of why neither was understood.
• No skeleton loader, because people will think it's a technical issue on a screen they already suspect. A named loading state instead.

UX goals

Six goals came out of the research, and they drove every screen that followed.

1. Reduce visual and cognitive clutter

   Solution

   Show less at rest. The old layout put every entry on screen at the same weight, which is why partners described it as overwhelming.

2. Improve data hierarchy and scannability

   Solution

   Give the figures that get checked most the strongest typographic treatment, so the screen can be scanned rather than read.

3. Make it easier to filter and search client-specific data

   Solution

   Filtering was already the most used tool. It needed to be first-class rather than a workaround for a poor default.

4. Design for mobile accessibility

   Solution

   The sheet had no mobile version at all, so partners away from a desk had no access to their own earnings.

5. Support various revenue types

   Solution

   Referral, team and bonus revenue existed in the business but had nowhere to live in the interface.

6. Introduce collapsible charts and graphs

   Solution

   Analysis had to fit a phone screen without becoming a scrolling wall.

The default view now answers the question partners actually asked. Revenue is summarised per client, with a product-wise breakdown in visual chips and percentage indicators, and a direct route into that client's transactions.

The chronological list survives, because reconciliation still needs it, but as a deliberate second view rather than the only one. It lists every trade or policy-level transaction with filters for product type, revenue type, date range and status (locked or unlocked), plus integrated "Download Report" and "View Details" actions.

A dedicated view per client: a monthly revenue trend graph, a category-wise pie chart, and every transaction for that client with a download and export option.

Pie charts and line graphs help partners visualise revenue trends and category performance. These visual elements transform raw numbers into intuitive insights, giving partners a high-level analytical view of their revenue streams, which is the thing they had been leaving the product to get.

Mobile, for the first time

The mobile brief was not a smaller web page. A partner checking earnings on a phone is usually answering one question, not auditing a month, so the mobile design starts from the summary and lets the detail be asked for.

To handle space constraints on smaller screens, monthly charts sit in collapsible sections. Partners expand only the segments they need, which reduces cognitive load and visual clutter while still providing access to detailed trends.

The client details screen gives a quick, scannable view of all transactions per client in a clean, chronological format.

Transactions use a two-level list. The first level shows client name and revenue amount for quick scanning; on tap it expands to reveal revenue type, order number, folio, payout date and the revenue calculation. The detail is there without being in the way, which is the same argument the collapsible charts make.

Filters narrow the data by product type, revenue type, revenue status and transactions. Research had already shown filtering to be the most used tool on web; on a phone, where far less fits on screen at once, it carries even more of the work.

Before and after

Drag the handle to wipe between the two.

BeforeAfter