The Story Behind the Count: Data Visualisation for a Privacy-Centric Product

Overview

Showing members how their accounts change over time

Yorba scans your email and banking to find the relationships you have online: logins, subscriptions, mailing lists, data breaches. The dashboard told members how many of each they had. Static counts, with no sense of whether things were improving or getting worse after you took action.

This project added data visualisation to each account type screen so members could actually see movement over time and make better decisions about what to do next.

A visualisation in a subscription product isn’t decoration and it isn’t reporting. People renew a product they can see working, and Yorba’s whole promise is that your exposure gets smaller. The counts proved the product had found things. Nothing proved it was doing anything.

The Problem

Counts without context

The dashboard showed totals. Subscriptions that charged you money sat alongside logins and mailing lists that did not, emails lived on a separate screen, and everything was static. A net change figure told you where you stood, and the stats could scope it to a month, so an afternoon spent unsubscribing from mailing lists did register. What they could not do was set those months side by side: whether the number had been climbing all year or had finally started to fall. No trajectory, no feedback loop.

A previous Shape Up cycle had already split account types into their own screens with stats and tables. That was a real improvement, and it cost something members valued. An analytics page had shown the whole data footprint in one view, split by what was costing you money and grouped by category. It was removed because its story no longer matched the per-relationship narrative, and because a page of its own led nowhere: you could study it and still have nothing to do.

So the gap was not that members had never had a picture. It was that the one they liked had been in the wrong place, and the screens that could actually drive action had none.

Research & Discovery

Data constraints shaped the charts

The previous cycle set the direction

Separating account types into distinct screens had already been validated. This project picked up from there and extended the work into visualisation.

Each account type needed a data audit

Before I sketched anything, I mapped three layers for each account type: what data the platform actually had, what could be derived from it, and what meaning that derived data carried for someone deciding what to do next. Then I matched chart types to the question each screen needed to answer.

Labels had to land with a general audience

Interviews and usability testing checked whether the charts communicated what we intended. Every label, axis name, and category had to make sense to people who aren't comfortable reading charts. A copywriter helped get the wording right.

Design Process

Matching the chart to the question

Extending what was already there

I built on the stats structure from the prior cycle. Charts had to extend what those screens already communicated, not sit alongside them as decoration. Quick filters came up in testing, but the UI complexity and engineering effort didn't justify prioritising them over the core visualisations.

One page, one ask

Charts and tables share a screen, and both are affected by the same plan limits: the trial ending, how deep a scan runs on basic. Both needed empty and partial states, and the obvious version gives each one its own message and its own prompt to upgrade.

I gave that job to the table. A chart with thin data can say so plainly and stop there; the table carries the full state, including the upgrade. On a screen about how exposed you are, being asked twice in one scroll is worse than being asked once and better.

The charts’ own empty logic is deliberately smaller: no data, a single entry, an outlier wide enough to flatten everything else. Enough to stay honest about what it’s drawing, not enough to compete with the surface below it for the same conversation.

Deciding the right chart

The one that didn’t ship

The four charts answer questions about one account type at a time. There was a fifth direction that didn’t ship: a homepage module, carousel-style, with a panel for each relationship, framed as a trend you could watch rather than a count against a target.

It was killed, and for the right reason. The panels were monthly snapshots that did not measure the way the charts on the relationship pages did, so the same relationship could read differently depending on where you looked. That inconsistency was not worth carrying for a view adding little the individual pages were not already giving.

What it was reaching for was correct, though. A count against a backlog tells you what is undone. A trend tells you your effort is working, which is what this project was for. It wasn’t mature enough to ship and that was the right call for a half-formed idea, but it’s the direction I’d push harder on now.

From chart to action

Each visualisation sits above the detail table. Where it makes sense, interactive elements filter that table directly. The chart is never the destination. It leads to a decision, and for most account types, it shows the effect of decisions already made.