Reporting & Analytics System
Redesigned reporting from fragmented widgets into a scalable analytics system with report boards, premade dashboards and a Custom Widget Builder.
- Role
- Senior Product Designer
- Period
- 2025
- Focus
- ResearchReporting UXWidget builder
- Product context
- ScomplerSaaSAnalytics
Overview
I redesigned Scompler’s reporting experience from a fragmented set of low-value analytics widgets into a coherent, scalable system spanning embedded analytics, structured report boards, reusable widget logic and a Custom Widget Builder.
As Product Designer, I owned problem framing, research synthesis, UX architecture, interaction design, prototyping and validation with clients, stakeholders and internal teams. The work translated complex data relationships and real user questions into a reporting model that could scale across the product.
Context and problem
Scompler is a complex B2B SaaS platform for strategic content planning and orchestration. It connects Topics, Stories, Articles and Multi-Posts with strategic planning, execution and performance data.
Planners needed to understand distribution, strategic alignment and trends across themes, stories and campaigns. Channel Managers needed fast visibility into performance, comparisons and communication-ready outputs. Reporting was the layer where strategy, execution and measurable outcomes needed to come together.
The legacy system did not make that value usable. Widgets were low-value and poorly aligned with user questions; reports were rigid, filtering was confusing and analytics fragmented across embedded views, reports, dashboards and widget families. Users often finished analysis in Excel, PowerPoint or external BI tools.
Legacy reporting gaps
Research and reframing
The redesign centered on two core groups: Planners, who work closer to strategy, and Channel Managers, who work closer to execution. Research combined client interviews, internal product knowledge, customer-facing feedback, competitor review and later prototype validation.
Users needed both overview and depth: quick summaries for daily work, with the ability to drill into specific questions. They consistently needed comparison, segmentation and filtering, while trust depended on understanding what data they saw and why. Many reporting tasks ended with communication for reviews and stakeholder discussions.
This reframed reporting from a fixed set of widgets to configurable analysis: structured premade views provide a starting point, then users can go deeper through filtering, comparison and custom widget creation.
System design foundation
The redesign began with the system, not screens. I helped define the datasets the reporting model could operate on: Articles, Stories and Social Signals. A feature data map connected user questions to datasets, dimensions, metrics, filters and valid chart types.
That map translated research into reporting logic: what can be measured, how data can be grouped and which combinations are meaningful or should be restricted.
Shared widget grammar
Each widget used the same building blocks: metric, dimension, chart type, filter logic, comparison logic and, where relevant, a summary state. This shared grammar created a consistent mental model across Reports, Dashboards and the future Widget Builder.
Key solution moves
The solution was a connected set of product moves, not a single screen. Together, widgets, filters, comparison logic and the Widget Builder formed a flexible analytics ecosystem.
Structured report boards
Isolated charts became tab-based report boards. Each board represented a clear reporting context or purpose, creating analytical order and a stable starting point rather than a blank state.
- Reports are organised into purposeful spaces.
- Widgets live inside a clear structure.
- Analysis starts from a board, not a blank state.
Role-based premade widgets
Planners and Channel Managers made different decisions with different data. Instead of one generic widget library, the system offered role-specific sets of ready-to-use widgets mapped to their questions, datasets, dimensions, metrics and chart types.
- Planner widgets: content distribution, strategic alignment, portfolio comparison and trends across stories, topics or business units.
- Channel Manager widgets: channel performance, engagement quality, format effectiveness and time-based monitoring.
Filters and comparison as core actions
Filtering and comparison became explicit reporting actions rather than secondary controls. Clearer scopes and comparison across periods, channels or segments let users test assumptions, narrow a view and build an analytical story without leaving the report.
Export for communication
Reporting also needed to support communication. I designed an export layer that made report content easier to capture, format and reuse in manager, client and stakeholder discussions, reducing the gap between finding insights and sharing them.
Widget Builder as the flexibility layer
Premade widgets provided speed, but advanced users also needed controlled configuration. The Builder lets them choose datasets, grouping, chart types, filters and comparison settings while preserving the shared reporting model.
- Boards provide structure.
- Premade widgets provide speed.
- Filters provide exploration, export provides communication and the Builder provides customisation.
Validation and iteration
The system was iteratively prototyped and reviewed with clients, internal stakeholders, product and design teammates. Validation covered report-board structure, premade widgets, filter and comparison behaviour, and the Widget Builder interaction flow.
Feedback repeatedly asked for clearer structure and terminology, guided starting points with enough depth, and explicit filter and comparison logic. The result was clearer report organisation, more predictable widget behaviour and a guided Builder flow with validation and preview.
Outcome
Post-launch product metrics were not available within the project scope. The redesign nonetheless produced a clearer, scalable reporting capability validated through prototyping and stakeholder feedback.
Reporting evolved from disconnected screens and rigid widgets into one ecosystem of shared datasets, reusable widget logic and connected surfaces. Users could start with premade reporting views, understand the logic behind results and deepen their analysis through filtering, comparison and custom configuration.
Reflection
What worked
- Framing reporting as a system-design challenge, not a widget redesign.
- Building around real user questions, roles and reporting scenarios.
- Standardising widget logic before adding flexibility.
- Treating reporting as both analysis and communication.
What was hard
- Balancing simplicity and flexibility without making the system too rigid or too complex.
- Reconciling reporting logic distributed across multiple product surfaces.
- Making dataset, filter and comparison relationships understandable enough to earn trust.
What I learned
- In analytics products, trust is as important as functionality.
- Datasets, grammar and interaction logic need to precede polished UI.
- Premade and custom experiences work best as progressive layers of one model.
Featured Projects
My product design cases from the last few years.
