work / reporting-hub

The Reporting Hub

A design system that made enterprise analytics feel designed

Design Founding Designer · 2025–2026

Worked with Solo designer · collaborated with the product & customer success teams, driven by customer feedback

Visit thereportinghub.com ↗
Design System Created & delivered
Full Component library
WCAG Accessibility audit
TL;DR
  • Came on as the founding designer for an early-stage team with paying customers but no design bandwidth; ran the audit solo and built the design system from scratch
  • Customer success was weak because key information lived in docs; with the product deployed on client servers, no telemetry coming back, no chat support, the UI itself had to carry the knowledge
  • Key decision: standardised on Bootstrap 5 and delivered design specs for every custom component, a common language the developers could actually build

The real problem

The Reporting Hub is a white-label Power BI portal built by a lean, early-stage team that already had paying customers, which is exactly why design kept losing to the roadmap. Three problems compounded:

  1. No design bandwidth. The team couldn’t focus on design while serving customers, so I took up the responsibility: a full design audit, findings presented with concrete improvements.
  2. Information invisibility. Customer success was weak because the answers existed, in the docs, but not where users were. And this isn’t a traditional SaaS deployment: the product runs on client servers, with no telemetry coming back and no chat support to catch confusion live. Whatever users needed to know, the interface itself had to teach.
  3. A fast-built stack. The web app had grown quickly, accumulating custom components. The redesign looked great, but needed a common language with the developers to ever ship.
Goal

Audit the product, make its knowledge visible in-context, and deliver a design system the existing team could implement and maintain.

Outcome

WCAG-checked audit with prioritised improvements; key information surfaced as tooltips, hover-to-view and purposeful popups with visible cues; Bootstrap 5 chosen as the shared language, with design specs for every custom component.

What was considered

Rely on documentation
Why considered The information already existed there
Why it didn't ship Users don’t leave the product to read docs; with no telemetry or chat support, every confusion died silently on a client server
shipped In-product visibility (chosen)
Why considered Tooltips, hover-to-view and popups where necessary, each with a visible cue, make the product feel relevant and human at the moment of need
Trade-off accepted Every surfaced hint had to be curated; over-tooltipping is its own UX failure
Bespoke design system
Why considered Maximum design control and brand expression
Why it didn't ship A lean team can’t maintain a custom framework; Bootstrap 5 plus specs for the custom components met the developers where they were

Scope of work

Design AuditComprehensive UI/UX and WCAG accessibility analysis, presented with improvements
Information VisibilityTooltips, hover-to-view and popups with visible cues, doc knowledge moved into the UI
Design SystemBootstrap 5 foundation with design specs for every custom component
Implementation GuideStep-by-step setup, migration, and deployment documentation