Labels Home

The case for changing it was mostly internal. Our PM called the tables repetitive, I found the page confusing to land on, and two tickets covered slow loads and rows you couldn’t click. Nobody had asked labels about the home page directly. Doing that became a big part of the project.

I built it in code so labels could react to something real. I directed the build and made the design calls, with our PM’s edits along the way, and Claude Code wrote the code on top of our design-system tokens. At the time, I found the quality much higher working in code than in our static tools.

I made two versions. One was the full vision, with everything we wanted on the page. The other was scoped to what our data and APIs support today, so engineering could see what could ship first. Labels saw the full vision, on a demo account.

Engineering walked through it in July, and nobody had blocking concerns about putting it in front of two labels. It only ever ran locally, for testing.

Shorter time windows, to catch spikes on older tracks. Fewer pins, so a quick look stays quick. A way from a spiking track to the artist’s other releases. Royalties by quarter. Plainer words for release versus track. And a clear view of which analytics exist.

Highlighted became the top five by growth, with a 24-hour, 7-day and 28-day control. One label wanted the shorter windows to catch spikes on older tracks that a 28-day window hides. Our growth data only covers 28 days today, so the shorter windows ship disabled until it does.

The watch list became pins: five tiles and an add slot in a fixed row, so the page never grows. The cap is my proposal. Labels named anything from three to ten.

At the first label, participants put Needs attention near the top on their own. It is now worst first: taken down, then needs edits, then a pending action that names what is missing, like production credits. Each release is one row, the whole row opens the fix, and there is no dismiss. Three rows show, and the rest open in a drawer.

No label has seen this version. The ranked top five replaced the moving ticker, which drew the first unprompted reaction in the first session, so that is the first thing I would test.

Next round, I want labels to drive, with tasks: find what needs fixing and fix it, find your fastest-moving release, and check what you are owed. And I would test the buildable-now version, so we learn what is worth shipping first.

We never set success metrics, and I would fix that before build. Round two proposes some, like time from landing on home to fixing a release, click-through to analytics, and pins per label.

I owned the PRD and the design, directed the build, drove both label sessions, and did the synthesis and round two. Claude Code wrote the code under my direction.

Our PM raised the problem, co-led the June direction, gave edits on the build, chose the labels, hosted the sessions and holds the round-two decisions. A front-end engineer walked through the build with us and proposed building it in phases.