Shayan

Helping Sellers Make Smarter Decisions

My role:

Product Designer

Main collaborators:

This is a brief look—curious about the full story? Reach out to me.

Copied. Say hello anytime.

Context & Background

Tradeling is a B2B marketplace where many sellers run a serious chunk of their wholesale business. Seller Center includes a Performance Analysis module that should act as the "brain" on top of Orders, Catalog, Finance, and Logistics - the place sellers go to understand performance and decide how to grow on Tradeling, not just check numbers. By the time we started this project, both GMV (total order value on Tradeling) and the number of active sellers were growing fast. At the same time, refund volume was also increasing, signalling more financial risk and operational friction. The marketplace was clearly scaling, but the cost and risk of that scale were growing too.

Problem & Strategic Requirements

Discovery with sellers, Finance, Seller Success, and Ops showed two layers of problems:

  • 1. User-level issues:
  • Sellers didn't trust the numbers: the same "sales" or "refund rate" could show different values across Seller Center, ERP, and finance reports, mostly due to inconsistent Source of Time (order vs delivery vs financial posting).
  • The Sales module was descriptive, not actionable. To understand a refund spike, people exported to Excel, built custom pivots, and pulled in Support or Finance.
  • Refunds were the worst area: high financial impact, unhappy buyers, and no clear story about causes or what to fix.
  • 2. Tradeling-level requirements:
  • For Tradeling, this wasn't a "UX clean-up" problem. The business needed this module to:
  • Grow revenue: help sellers grow GMV on Tradeling (more commission and higher ARPU), and shift more of their B2B sales from offline and competitors into Tradeling.
  • Improve seller retention & stickiness: make Seller Center the primary place sellers check performance and make decisions, not "just another data source" they export and ignore.
  • Reduce operational cost at scale: cut repetitive "your numbers are wrong" tickets and reconciliation calls, so Support and Finance could scale without proportional headcount.
  • Underpin the "data partner" positioning: without a trusted, actionable analytics layer, it's impossible to credibly sell advanced services like logistics, credit, or future forecasting/alerts.

The requirement from Tradeling's side was clear: turn the Sales Performance module into a trusted, decision-support surface that can drive revenue growth, retention, and platform stickiness - not just fix a few confusing charts.

Performance dashboard before state 1
The old version of the Seller's portal - sales performance dashboard - overview tab.
Performance dashboard before state 5
The old version of the Seller's portal - sales performance dashboard - refund and cancellation tab.

Key Decisions & Constraints

We were working on a live product with limited engineering bandwidth and real-world data constraints. Three decisions shaped the approach:

  • Fix the foundations before chasing “smart” features: We prioritised cleaning up Source of Time and definitions over adding new visualisations or forecasting. Without that, any “smart” layer would just amplify mistrust.
  • Go deep where the pain is sharpest: Rather than lightly touching every tab, we chose Refunds as the pilot for a true insight-driven experience, because it sits at the intersection of buyer experience, seller revenue, and internal cost.
  • Keep insight logic transparent: We avoided overly complex, opaque algorithms and chose a straightforward approach, so Finance, Ops, and sellers could understand how each insight is produced and decide whether to trust it.

The Solution

We focused the first iterations on two moves:

  • 1. Source of Time (SOT) foundation
  • We made time logic visible and predictable by adding context-level SOT controls on Sales tabs, and by locking the Refund & Cancellation tab to Financial Date with clear copy. This aligned what sellers see in analytics with what Finance reports in the books and reduced "which number is correct?" debates.
  • 2. Refunds as a guided insight experience
  • We then redesigned the Refund & Cancellation area as the pilot for a proper decision-support flow:
  • A focused Refund tab with KPIs (refund rate, refund amount, average refund per order) and charts (over time, by reason, breakdown table), all explicitly tied to Financial Date.
  • A prominent “View insights” entry point that opens a modal structured as What happened / Why / What next:
  • What happened – short narrative about how key refund metrics moved in the selected period.
  • Why – up to three driver insights (e.g., damaged items in specific categories/warehouses), each with “View evidence” that opens the Refund tab pre-filtered to match the story.
  • What next – links into operational surfaces like SOPs, warehouse checklists, or supplier QA (including an “Edit SOP document” flow for relevant patterns).
  • “Was this helpful?” feedback on insights to tune rules, thresholds, and wording over time.

Together, this turned Refunds from “some charts you glance at” into a detect → diagnose → act flow and laid the groundwork for the next evaluation layer (actions & impact on charts) and for extending the pattern to other parts of the Sales module.

An overview of the new version Seller's portal - sales performance dashboard - refund and cancellation tab.

Outcome & Impact

In the first 3–4 months after rolling out SOT + Refund Insights to an initial cohort, we saw:

  • 1. Adoption and behavior
  • Around 35–40% of sellers visiting the Refund tab clicked "View insights" at least once a month; About 20% of them came back to it in multiple months.
  • Roughly 25–30% of insight sessions led to at least one concrete action (for example, “View evidence”, Edit SOP, or View supplier QA), which showed that people were not just reading the story — they were acting on it.
  • 2. Support & internal efficiency
  • Refund-related clarification tickets per active seller dropped by roughly 20–25%.
  • Median resolution time for those tickets decreased (from ~2.5 days to ~1.5–1.7 days), as Support and Finance could anchor discussions on the same SOT-aligned view.
  • 3. Early business signals
  • For a pilot group of engaged sellers, damaged-item refund rates in targeted categories (e.g., Dairy & Beverages) decreased by roughly 10–15% quarter-on-quarter.
  • Refund amount as a share of GMV improved by around 5–10% while GMV itself stayed healthy.

Account managers reported they could now run refund conversations inside Seller Center — open the tab, click insights, walk through the story, and agree on actions — instead of stitching the story together in spreadsheets.

My Role

I was a Product Designer on this work, embedded in a cross-functional squad:

  • Partnered with Sara (UX Researcher), Uras (Senior Product Designer), Jordi (Head of Design), Philip (Design System Manager), Aida (PM), and Unais (Data Engineer).
  • Co-led discovery with Sara and Aida: seller and internal interviews, support ticket and analytics review, and synthesis into JTBDs, problem statements, and hypotheses.
  • Helped shape the phased roadmap (SOT foundation → Refund Insights → future comparison & alerts), pushing to fix foundations before adding “smart” features.
  • Designed the Source of Time interaction model and aligned with Finance on which time base each key Sales metric should use.
  • Owned the UX for the Refund & Cancellation experience, Refund Insights, and the Recent Actions & Impact feature. Also, the cross-module actions like Edit SOP, Open Warehouse Checklists, and more — working closely with engineering and data through implementation and QA.
Helping Sellers Make Smarter Decisions — Shayan Khalilian — Shayan Khalilian