Charts we didn't ship.
A small museum of designs that died on purpose — and what each one was trying to be.
Lede
A design system is judged by what it ships. It is built by what it doesn't. Here are three charts that almost made it into the product, and the reason each one didn't.
The drawer
We keep a drawer — literally, in Figma; spiritually, in an unmerged branch — for charts that were close. They are not failures, exactly. They are mostly correct ideas that were not the right answer for the problem we were solving. We open the drawer, every quarter, and ask whether any of them have aged into the right answer. So far the drawer is undefeated.
The heatmap
The first chart in the drawer is a service-by-hour heatmap of pager activity. It looks beautiful: a calendar grid of small squares, each colored by a count, with the loud hours obvious from across the room. We built it because we wanted a way to spot the bad weeks at a glance.
It died because nobody acted on it. The bad weeks were already known to the team that lived through them; the heatmap was a postcard from the past. By the time a square was dark enough to draw the eye, the incident behind it was either already fixed or already a habit. We were not lacking the information; we were lacking the appetite to confront it. A heatmap, it turned out, was not the right way to confront anything.
The ring
The second chart is a circular dependency view of services, drawn as a ring with arcs between nodes. It is, visually, the kind of thing that gets a chart pinned to the wall. It is also, on inspection, a confession that we had a circular dependency graph — a problem we should have been solving, not visualizing.
A chart that makes a problem look beautiful is sometimes a chart that has been hired to keep the problem.
We removed the chart. We then removed two of the cycles. The chart, if it still existed, would now show a much less interesting ring — which is to say, a correct one.
The radar
The third chart is a six-axis radar showing the “health” of a service across latency, error rate, queue depth, deploy frequency, oncall load, and on-time SLO. It tested well in usability sessions. People liked the shape. They could tell, at a glance, whether a service was “balanced.”
It died because balance was not the goal. A service can be balanced and bad — equally mediocre on every axis — or it can be unbalanced in exactly the right way for what it does. The radar made the question “is this service well-rounded” into the question we were asking, when the question we should have been asking was “is this service serving its purpose.” We shipped a different answer.
The chart we shipped
The chart we shipped, in place of the radar, is a single sentence written by the system: a paragraph that names the service, its current load, and the thing it is closest to failing at. There is no shape. There is no axis. There is, on most days, almost nothing to read. That is the chart.