The dashboard made of pie charts
Redesigned a confusing pie-chart dashboard and built the most complete handover package I could, to make the frontend implementation as easy as possible.
- Context
- B2B SaaS / analytics dashboard
- Role
- Product Owner
- Date
- January 2026
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 got a working package instead of a wish. 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
A statistics dashboard built out of pie charts that no one could read a trend from, and no spare design or frontend capacity to fix it.
I prototyped the replacement from the backend API contract and handed frontend a working package rather than a wish, with states, data shapes and edge cases included.
Problem
The existing statistics page relied on pie charts and unclear terminology, which made campaign outcomes harder to read. We had no dedicated UX/UI function in the company, so interaction design and usability decisions also sat with me. At the same time, implementation capacity was constrained, so a full redesign through the normal handover flow would be slow.
I needed a way to reduce delivery time without lowering clarity or implementation quality.
Approach
I used AI as a prototyping and coding partner, while I stayed responsible for scope, language, quality checks, and delivery decisions.
The workflow was simple.
- Define user-facing outcomes and terminology rules
- Iterate rapidly in browser on layout, chart behaviour, and interaction details
- Pressure-test edge cases (for example, many UTM sources and PDF export behaviour)
- Package the result for front-end implementation with explicit handover documentation
What I learned
AI-assisted delivery worked best when I kept product ownership explicit. I defined the constraints, validated the behaviour, and documented unresolved API questions clearly.
This project also confirmed that strong handover quality can be a direct time-saver for engineering, especially on UI-heavy work.
One thing would have made the handover package better, read access to the codebase. I had to ask developers which API endpoints were used to calculate the statistics, which added a round-trip and left some questions open. If I had been able to read the source code with AI support, without changing anything myself, I could have used the actual endpoint logic and data shapes to produce a more accurate prototype and a tighter handover. The output would have required less back-and-forth from engineering to implement.
That is the broader point I took from it. Product owners with read access to the codebase can close a lot of the gap between what gets prototyped and what actually ships.
- January 2026Set redesign goals and replaced pie-chart-first thinking with clearer chart hierarchy.
- January 2026Refined Swedish terminology to better match the customer journey and reduce ambiguity.
- January 2026Iterated on visual hierarchy, including emphasising success metrics and removing noisy signals.
- January 2026Solved scaling issues for large source lists by introducing dynamic chart height behaviour.
- January 2026Adjusted PDF output for practical reporting and cleaner print behaviour.
- January 2026Finalised handover package with implementation docs, open API questions, and integration guidance.
Prototype
I delivered a full handover package to reduce front-end implementation effort.
- Standalone working prototype (
statistics.html) - Angular component version (
.ts,.html,.css) - Technical handover documentation and terminology guidance
- Change log and quick-start documentation
Package size was about 149 KB across 10 files, with both standalone and framework integration options.
