Analytics Dashboard Redesign

Overview

Apteco’s analytics module allowed marketing teams to track campaign performance, audience behaviour, and channel effectiveness across multi-channel programmes. The data was sophisticated. The presentation was not.

The existing dashboards had been built to display data, not to support decisions. Every chart was available, every metric was shown, and nothing was prioritised. Marketing analysts spent more time constructing the right view than interpreting what they found.

I was brought in to redesign the dashboards with a clear brief: help analysts spend less time finding data and more time acting on it.

Business Context

The analytics module was a key differentiator in sales conversations. Apteco’s data engine was genuinely more powerful than competitors for marketing attribution and audience analysis. But the gap between what the data could show and what users could see in the interface was significant.

Account managers were consistently hearing from clients that the analytics were “hard to use.” Customer success teams were spending time on data interpretation rather than strategic guidance. There was a commercial case for improving the analytics experience: clients who used analytics features at least twice weekly had a 34% higher renewal rate than those who didn’t.

Problem

After a week of observation sessions and a review of analytics feature usage data, the problem became clear:

The existing dashboards were built for analysts who already knew what they were looking for. There was no entry point for someone who wanted to understand how a campaign had performed overall before drilling into specifics. Every dashboard started at the maximum level of detail.

Additionally, the customisation burden was high. Because no default view was useful, every analyst had to build their own views from scratch. This was time-consuming and meant that knowledge about useful configurations was not shared across teams.

Constraints

• The underlying data model was fixed — I couldn’t change what data was available, only how it was presented
• Performance was a concern. Some clients had datasets with hundreds of millions of records. The design needed to avoid queries that would time out
• Custom report builder functionality had to be preserved — power users relied on it and it was a differentiating feature
• The engineering team was small and the sprint budget was tight

Research

I ran a compressed research programme over 3 weeks:

• 10 contextual interviews with analytics users across 4 client organisations
• Session recording review (100 sessions across 5 accounts using Hotjar)
• Analysis of support tickets related to the analytics module
• Interviews with 3 account managers about the most common client feedback

From session recordings: 68% of sessions began with the user navigating to the custom report builder within the first 3 minutes. The default dashboards were being bypassed almost entirely.

From interviews: Analysts described three primary tasks they came to analytics to complete: (1) check whether a campaign had hit its targets, (2) understand which audience segments had responded best, and (3) compare performance across channels. None of these tasks had a clear home in the existing interface.

Insights

Insight 1: The entry point was wrong. Analysts had a question when they arrived. The existing interface presented data without a question framework. The redesign needed to organise content around the questions analysts most frequently asked.

Insight 2: Comparison was the most valuable action. Most analytical insight came from comparison — this campaign vs last campaign, this segment vs that segment, email vs SMS. The existing interface made comparison require multiple steps and a custom report.

Insight 3: Default views needed to be useful, not comprehensive. The instinct in the existing design had been to show everything. The right approach was to show the most important things well and make it easy to go further.

Product Thinking

The most important product decision I influenced was the shift from a widget-based dashboard to a question-based navigation structure.

The existing product was organised by data type: Campaign metrics, Audience insights, Channel performance. I proposed reorganising around the three primary questions analysts had: “How did this campaign perform?”, “Who responded?”, and “How did channels compare?”

This sounds like a small change. It was not. It required rethinking the entire IA, which metrics were shown by default, and which visualisations were appropriate for each question context. It also required the PM to accept that the product structure would no longer mirror the underlying data model — a significant shift for a data product company.

The PM agreed after I presented the session recording data showing that analysts were bypassing every default view.

Key Decisions

Decision: Campaign summary card as the default entry point. When an analyst opened a campaign, they first saw a summary card: targets vs actuals, top-performing segment, best channel. No configuration required. This gave immediate value and a clear path to deeper investigation.

Decision: Comparison built into the primary visualisations. Rather than requiring analysts to build a comparison view, the primary charts included a comparison toggle — this period vs previous period, or this campaign vs selected benchmark. The most common comparison task went from 4 steps to 1.

Decision: Progressive disclosure for complexity. The full custom report builder remained accessible but was not the first thing users saw. Analysts who needed it could access it — but the default experience guided them to an answer before offering them full control.

Design Process

The design process had two phases. The first was structural — defining the IA and the question-based navigation model. I ran three workshops with the product team and two client advisory sessions with power users to validate the structure before moving into visual design.

The second phase was visualisation design. The key challenges were:

1. Choosing the right chart type for each question context — campaign performance needed different visualisations than audience analysis. I worked through this systematically with the data team.
2. Designing comparison states — showing this period vs previous period required careful handling of colour, labelling, and legend design to avoid misinterpretation.
3. Empty and loading states — for clients with large datasets, some charts took 3-5 seconds to load. The loading state design was critical for preventing users from thinking the chart had failed.

Validation

I ran two rounds of moderated testing with 12 participants (6 power users, 6 intermediate users):

• Round 1: The campaign summary card was immediately understood by all participants. The comparison toggle was missed by 4 of 6 intermediate users — it was positioned too close to the chart title. We moved it to the chart toolbar.
• Round 2: Validated the full flow. All participants completed the three primary tasks without assistance. 4 participants described the default view as “what I’ve always wanted.”

Final Solution

The redesigned analytics module is structured around three primary views, accessible from the campaign detail page:

Campaign performance view: Default entry point. Shows targets vs actuals, trend over campaign period, and top 3 performing segments. Comparison toggle for period-over-period analysis.

Audience breakdown view: Segment analysis with demographic and behavioural breakdowns. Designed for the “who responded?” question.

Channel comparison view: Side-by-side channel performance, with normalised metrics to enable fair comparison across email, SMS, and direct mail.

The custom report builder remains accessible from a persistent “Custom analysis” link — visible without being primary.

Collaboration

The primary challenge was working with the engineering team on performance constraints. Several of the visualisations I designed required aggregation queries that were slow on large datasets. We worked through a series of design-engineering sessions to find alternatives that achieved the same analytical goal with more efficient queries.

The most effective tool was a shared constraint document that listed every known performance threshold and the dataset sizes they applied to. Designing within documented constraints was more productive than iterating after engineering pushback.

The data team also became important collaborators. They had deep knowledge of what the data could and couldn’t show — and several of their suggestions for derived metrics (conversion rate by source, for example) became core parts of the campaign performance view.

Outcomes

Three months post-launch:

• Time-to-insight reduced by 40% (measured via structured task completion study with 20 users)
• Dashboard engagement increased 2.6x (sessions per user per week)
• Custom report requests to client data teams fell by 45%
• Satisfaction score of 4.2/5 in post-launch survey

Two clients who had been using competitor analytics tools switched their analytics workflow to Apteco’s redesigned dashboards within 6 months of launch.

Failure and Risk

The question-based IA worked well for the three primary questions I had identified. But it created a categorisation problem for analysts whose questions didn’t fit neatly into the three views. Several power users found the new structure more constraining than the old widget-based approach for exploratory analysis.

The solution — making the custom report builder more discoverable and adding a fourth “Explore” entry point — was shipped in the following quarter. I should have anticipated this gap.

The empty state design was also a recurring issue. When a campaign had no data yet — because it was scheduled but not started — the empty state looked identical to a loading state. Several users thought the dashboard was broken. This was fixed before launch but cost more time than it should have.

Reflection

This project reinforced for me that data products fail in a specific way: they prioritise data completeness over analytical usefulness. The instinct of data teams is to show everything available. The instinct of analysts is to find the answer to a specific question.

Designing the bridge between those two instincts — making comprehensive data accessible through a question-oriented entry point — is the core challenge of analytics UX. It is not a technical problem. It is a product thinking problem.