Pickle · Conversation Intelligence · 2022

Pickle Analytics Dashboard

Product designer · An analytics dashboard reframed from raw data to sales insight — the surface that carries Pickle’s core value.

01

Overview

Pickle is a Zoom app for sales teams: it captures every meeting, then turns the conversation into AI-driven analysis that helps account executives and sales leaders raise the quality of their calls.

The analytics dashboard is where that value is supposed to surface — and it had become the feature users engaged with least. Rebuilding it into something insight-driven, conversation-focused, and intuitive was the brief of this project.

02

Understanding

Problem Statement

Business perspective
  • Amplitude shows the split: as overall product engagement climbs, dashboard engagement falls — users lose interest in analytics precisely as they settle into the product.
  • Pickle also had no good way to deliver summarized meeting data back to customers — a real competitive disadvantage in this market.
An Amplitude line chart over twelve months: total product events and new users climb steeply through the year while the “viewed dashboard” line stays flat and low.
Amplitude engagement — the whole product vs. the analytics dashboard
The pre-redesign Pickle dashboard: four headline counters over a call-count line chart, a sentiment chart, a top-markers bar list and a markers-versus-sentiment scatter, with no summary or recommended next step.
The analytics dashboard before the redesign
User perspective
  • Hard to draw conclusions — the dashboard shows data, not insight.
  • Users want actionable takeaways, not raw numbers.
  • The data is too coarse to interpret: internal vs. external meetings, meeting types and phases all blur together.
  • No chart suggests a next step.
  • And overall — not an intuitive experience.

Defining Project Goals

The goals flip those complaints into targets: an insight-driven, conversation-focused, intuitive dashboard — one set of outcomes serving the user’s learning needs and the business’s engagement needs at once.

Three overlapping frames: user impacts (understand performance, uncover useful areas, boost revenue) and business impacts (users tie Pickle to their success, engagement and subscription rise, a framework for Pickle research) overlap on the project goals — an insight-driven personalized dashboard, meeting insights that improve performance, and team management that boosts revenue.

Empathizing with Users

Working from earlier research, our UX researcher Saniya mapped how sales teams actually collaborate — where needs go unmet, and where today’s workarounds live.

From that map and the project goals, we distilled three user stories to steer ideation.

Three user-story cards: an account executive and VP who want to interact with their conversation-intelligence data to know their next steps; an account executive who wants to find useful recordings and snapshots to learn best practices; and a VP who wants a per-rep performance breakdown to spot outliers and support the team.
03

Ideating

Prototyping for Usability Testing

With the team aligned on sketches, I built a clickable prototype for testing. Mid-fidelity was a deliberate choice: this dashboard lives or dies on real colors — red versus green — and real copy, so both had to be in the test.

Three things the testing had to answer:

  • Do the core and premium usage metrics actually help customers see Pickle’s ROI?
  • Does the visual encoding of those metrics read correctly?
  • Is the dashboard usable end to end?
The clickable prototype mapped out: an activity page and an interaction page organized by top tabs, a panel showing data for individual recordings, and the switch into manager mode with its team-performance view and editable team notice.
Prototyping meant rounds of adjustment — type, spacing, and new decisions fed by Saniya’s research input.
04

Iterating

Hi-Fi Iterations Based on Testing Insight

Five users tested the prototype. Four findings shaped the next round:

  • Consolidate information

    Users want the important data on one page, not spread across tabs.

  • Emphasize visual clarity

    Dense text repels; patterns should surface at a glance.

  • Streamline meeting access

    Account executives want fast paths to useful snapshots when preparing calls.

  • Technical constraint (from engineers)

    Some features would take months to build — out of scope for a short-term launch.

I split the hi-fi work into three focus areas — layout, charts, and flow — starting from the staff-mode homepage.

Four testing findings routed by arrows into three focus areas: simplify layout structure, optimize data representation, and develop the search and retrieve flow.

Prioritize User Needs

Every feature re-earned its place: kept, cut, or demoted, based on what testing valued and what engineering could carry.

An abstract before-and-after: two dashboard layouts drawn as blocks, all of them filled, become the same two layouts with several blocks greyed out.
The prototype’s two pages annotated feature by feature with keep, not-keep and combine-with-other-features calls, each carrying the testing or engineering reason behind it.

Optimize Data Representation

Users expect charts that are both comprehensive and instantly readable — two demands that pull in opposite directions. Each iteration traded information layers against legibility; when a layer didn’t earn its cost, it moved to the detail page. And familiar chart types won over invented ones: recognition is free, novelty is a learning cost.

Color became semantic. Random hues went away; brand purple carries structure, and red and green are reserved for bad and good — so overall performance reads before a single label is parsed.

Two iterations of the Top Questions panel: a plain list of questions with a comment count beside each, then a ranked bar chart pairing every question’s opportunity and lead volumes.
Iterations of “Top Questions”
Three iterations of Conversation Topics: a percentage bar list, then a deal-size by pipeline-stage matrix coloured by sentiment, then the same matrix with topic checkboxes that filter which rows are plotted.
Iterations of “Conversation Topics”

Simplify Layout Structure

Tabs diluted the dashboard’s one job: conveying state at a glance. Prioritization is what made a single page possible.

An abstract before-and-after: two dashboard layouts drawn as blocks, several of them greyed out, become a single layout with every block filled.
Three layout iterations of the staff-mode dashboard side by side, each one moving the Conversation Topics and Top Questions panels further up and giving them more of the page.
Layout iterations — “Topics” and “Top Questions” carry Pickle’s differentiating value, so the layout gives them the visual weight.
The shipped staff-mode dashboard on one page: four headline metrics across the top, the Conversation Topics matrix and Upcoming Tasks down the left, average meeting volume and Top Questions down the right.
The final staff-mode dashboard.

No layout survives first contact: several rounds of revisiting feedback separated the first draft from the version that shipped.

Develop Search / Retrieve Flow

Charts are entry points, not endpoints. I mapped the flow from any chart into detailed breakdowns, and from there to specific transcriptions and snapshots — queued for testing in the next development phase.

The retrieval path: the Conversation Topics matrix on the dashboard opens the full Topics page, where selecting a cell lists the meetings behind it with their transcript timelines and snapshots.
An account executive at their desk with the Pickle dashboard open on a laptop, the Conversation Topics matrix filling the screen.
05

Impact

The redesign tested positive in the final round — and after launch, the curve moved:

+6%Engagement rate, first month after launch
+14%Engagement rate, second month

Engagement rate = analytics engagement ÷ overall engagement; engagement = key events × weight.

06

Reflections

  • Choose the right representation

    Pick the graph for the user’s question, and be suspicious of invented chart types: familiarity is a feature.

  • Design and test with a strategy

    A clear plan for what each round must answer beats testing for testing’s sake.

  • Understand technical limits before designing

    Checking feasibility per feature before committing the layout saves the most expensive kind of rework.