Case study 07
Rebuilding a nine-year-old reporting engine — and getting the design right where a year of work hadn't
How I took over a stalled React rebuild of a 2016 PHP reporting system, evaluated every design requirement from scratch, and delivered a modern reporting experience that brought 30% more customers off competitor tools.
30%↑ adoption
More customers using the reporting engine vs. alternatives
9 years
Age of the PHP system being replaced — built in 2016
Fresh start
Restarted after a year of work that didn't meet the bar
Solo PM
Template-based reporting
Data visualisation
Colour systems
UX
The problem
A year of rebuild work that still wasn't good enough
The reporting engine was one of the platform's oldest systems — built in PHP in 2016, visually outdated, and increasingly difficult to extend. A team had been rebuilding it in React for a year. By the time it was handed to me, the rebuild still had significant visual and usability defects that made it unshippable.
These aren't simple reports. They contain complex data visualisations that need to be both comprehensible to the end client receiving the report, and straightforward to configure by the agency sending it.
The previous approach had treated this as a technical rebuild. What it actually needed was a product and design rebuild — starting from first principles on how each data type should be represented.
The constraint matrix
Four competing requirements that all had to be true simultaneously
Constraint 1
End-client facing, not brand-optimised
Reports are sent by agencies to their clients. They needed to feel like the agency's work product — not branded for our platform.
Constraint 2
Themeable but not custom
Agencies wanted to approximate their clients' brand colours without full custom colour support. The theme system had to give enough flexibility without opening the door to unreadable combinations.
Constraint 3
Attractive but not fatiguing
Reports can be long. Bold, high-contrast colours look great on a dashboard glanced at for seconds — they become exhausting in a document read for minutes.
Constraint 4
Colour-blind friendly
Multi-series charts rely on colour to distinguish data. Every colour palette had to work for users with colour vision deficiencies — which further constrained the already-narrow set of viable colours.
How I approached it
Manual evaluation of every data type — then iteration until it was right
I went back to basics: evaluated every data point in the reporting system individually and determined the right visualisation type for each — pie charts for composition, column charts for comparison, stacked area graphs for cumulative trends. Each choice made explicit, not inherited from the old system.
The colour work was the hardest part. Every constraint pulled in a different direction. Landing on a system that satisfied all of them took multiple rounds of full iteration — not just tweaks.
Reports that go to end clients are a direct reflection of the agency's quality. Getting the design right wasn't just a UX improvement — it was a product that agencies could be proud to put their name on.
Impact
30% more customers on the platform's own reporting — away from alternatives
There was initial pushback on launch — as there is with any significant UI change to a tool customers have built workflows around. With iteration based on that feedback, friction was resolved and the product stabilised.
The outcome that mattered: 30% more customers switched to using the platform's reporting engine instead of competitor tools or building reports manually. The previous system had lost customers to alternatives precisely because it looked dated. The new one brought them back.