Dashboard UX — 2025
Parcel Analytics
A reporting tool that answered every question except the one customers actually asked.
Support tickets asking where is my report fell by two thirds.
- Client
- Parcel Logistics
- Discipline
- Data-dense interface design
- Engagement
- 9 weeks, Jan to Mar 2025
- Team
- Three engineers, one data analyst, one support lead
Overview
Parcel gives its shipping customers a self-serve analytics portal covering delivery performance, exceptions and cost. It had 41 charts and a support queue full of people asking how many of my parcels were late last week.
The tool was not missing data. It was missing a point of view about which questions matter, and it left every customer to assemble their own answer out of raw material.
Role
Senior product designer, contract
9 weeks, Jan to Mar 2025 · Three engineers, one data analyst, one support lead
- Support ticket analysis across 1,200 analytics-related conversations
- Interviews with nine customers across three account sizes
- Information architecture and the default dashboard definition
- Chart, table, filter and export interface design
- Empty, loading, partial-data and no-permission states
- Accessible data table patterns including keyboard navigation
Problem
Reading 1,200 support tickets produced a much better research artefact than any survey. Customers asked five questions over and over, and none of the 41 charts answered any of them directly. Every one required combining two or three views and doing mental arithmetic.
The dashboard also opened on an empty state that asked customers to build their own view first. New accounts saw a blank canvas and a chart picker. Almost nobody built one. They filed a ticket instead, which is a rational choice when the tool asks you to do its thinking for it.
Process
The support queue as the research corpus
I tagged 1,200 tickets by the underlying question rather than the stated request. Five questions covered 78% of them. That list became the specification for the default dashboard, and it was already validated by a year of real customer behaviour.
An opinionated default view
Every account now opens on a dashboard answering those five questions, populated from day one. Customisation still exists, but it starts from something useful rather than from nothing.
Choosing chart forms deliberately
Comparisons across categories became bars, not donuts. Time series kept a zero baseline. Anything that was really a single number is presented as a single number with its change, not as a chart. Several visualisations were removed entirely, which improved the product.
Tables treated as a first-class interface
Most customers ultimately want rows they can export. The table got sticky headers, keyboard navigation, per-column sorting with announced state, and a genuinely useful export rather than a raw dump.
Designing the unhappy data
Partial data, delayed pipelines, permission-restricted metrics and genuinely empty periods all got explicit designs. A dashboard that only looks right on complete data is not finished.
Outcomes
- −67%
- Analytics-related support tickets
- 41 → 12
- Charts in the default experience
- +140%
- Weekly active use of the reporting portal
- AA
- WCAG 2.2 conformance on every data view
Cutting from 41 charts to 12 was the contentious decision internally. It held because every removal was traceable to a question no customer had ever asked.
Gallery
Tools
- Figma
- Amplitude
- Zendesk exports
- Observable
- Axe DevTools