The dashboard made of pie charts

The short version

The problem

A dashboard of pie charts nobody could read a trend from, and no spare design or frontend capacity to fix it.

What I did

Prototyped the replacement from the backend API contract, with states, data shapes and edge cases included.

What it was worth

Frontend could start from a working prototype and its documentation, with no discovery slot needed.

The call

With no UX function and no capacity, the fastest path was to build the answer and hand it over clean.

What changed

The statistics page was built out of pie charts, and its terminology did not match how customers talked about a campaign, so nobody could read an outcome from it. There was no UX function in the company, so interaction and usability decisions sat with me, and frontend capacity was spoken for, so a redesign through the normal handover route would have been slow.

I wanted to shorten that without lowering the quality of what frontend received.

I prototyped the replacement myself, with AI writing the code and me holding the scope, the wording, the checks and what got handed over.

• Define what a user should be able to read off the page, and the terminology rules
• Iterate in the browser on layout, chart behaviour and interaction details
• Push the edge cases, such as a campaign with many UTM sources, or what the PDF export does
• Package the result for frontend, with the open questions written down

It worked because the product ownership stayed explicit. I set the constraints, checked the behaviour, and wrote down the API questions I could not answer instead of guessing at them.

It also showed what a good handover is worth to engineering on UI heavy work. Frontend got a working page and its documentation instead of a description of one.

One thing would have made the package better. Read access to the codebase. I had to ask developers which endpoints fed the statistics, which cost a round trip and left some questions open. With read access, and AI to help me read it, I could have built the prototype on the real endpoint logic and data shapes, and frontend would have had less to translate.

That is the broader point I took from it. A product owner who can read the code, without changing any of it, closes much of the gap between what gets prototyped and what ships.

1. January 2026
   Set the goals and replaced the pie charts with a chart hierarchy a trend can be read from.
2. January 2026
   Rewrote the Swedish terminology to match how customers talk about a campaign.
3. January 2026
   Reworked the visual hierarchy so the success metrics lead and the noise goes.
4. January 2026
   Let chart height grow with the source list, so a campaign with many UTM sources still reads.
5. January 2026
   Adjusted the PDF output so it prints cleanly and can go into a report.
6. January 2026
   Finished the handover package, with implementation notes, open API questions and integration guidance.

The handover package, built so frontend could start from something that already worked.

• A standalone working prototype, statistics.html
• An Angular component version, .ts, .html and .css
• Technical handover notes and terminology guidance
• A change log and a quick start

About 149 KB across 10 files, with both the standalone and the framework route in it.