Incrementality

turning insights into confident actions

overview

Role

Product design (UX/UI)

timeline

2 months

tools used

figma

Content has been sanitized to protect confidentiality while maintaining process integrity

problem

The marketing analytics team was running a rigorous process for measuring campaign impact entirely by hand in Excel, using inconsistent processes for each company brand. For every campaign, incrementality testing was conducted across multiple rows of data using t-tests, confidence intervals, scores, and test-vs.-control holdout groups.

The original intent of the project was a lift-and-shift redesign: take the existing campaign reporting and rebuild it in Power BI.

It was quickly realized that a simple translation into a new platform was not what was required, and thus the project scope expanded.

goal

Create a new product that automates and standardizes the most painful parts of the campaign analytics process.


Approach

Observe the workflow end-to-end through a series of user interviews, rather than immediately working from the initial project brief, to identify bottlenecks and pinpoint enhancements.

User Interviews

I worked with two campaign analysts who collectively cover six brands for the mailing marketing channel. The sessions focused on observing their day-to-day workflow, from how they pull and consume campaign data to how they clean it and share the results with the business teams. In addition, I asked about their overall experience, frustrations, and the information they focus on most. A summary of these interviews is below:

Workflow Inefficiencies

Post-campaign analysis was run entirely in Excel, resulting in long hours spent on each report for every campaign. Analysts were expected to manually pull data, run their own calculations, and format the finished reports from scratch each time, with no clear standardization across the team.

Most of the information was copied and pasted from different sheets into a comprehensive primary sheet that displayed all breakdowns and totals. As the marketing process scaled across other channels (email, SMS, etc.), the workflow was not set up to scale with it.

The workflow spanned six distinct stages, from data requests to quarterly roll-ups, each with its own frustrations and concerns.

Stage-Wise Pain Points

“The way we pull our reports currently is very tedious. We have to literally take from a raw report and do a lot of filtering and cop-pasting and creating these templates every time.”

Campaign Analyst

After the user interviews, I was able to isolate the six stages and corresponding challenges that consistently surfaced throughout the conversations:

  • Stage 1 – Request Intake: Vague campaign timings and information errors consistently occurred before any actual analysis even started.
  • Stage 2 – Data Processing: Analysts waited up to several weeks for data processing to be completed after a campaign ended.
  • Stage 3 – Manual Enrichment: Hours of copy-pasting across multiple tabs to separate the required data.
  • Stage 4 – Filtering and View Creation: A time-consuming filtering process repeated dozens of times per campaign.
  • Stage 5 – Analysis and Commentary: The lengthy task of merging scattered metrics into a single executive view that required handwritten notes and explanations.
  • Stage 6 – Quarterly Roll-Up: A multi-day manual process built on a hidden tab with hard-to-explain metrics and results.
Outcome

The discovery activities uncovered three key findings that were not mentioned in the project brief: the correct bottlenecks to target, an updated project scope, and an initial outline of product enhancements.

Feature Identification and Prioritization

The initial outline of product enhancements was refined by evaluating each proposed enhancement against two criteria: whether it was technically achievable in Power BI within the delivery timeline and whether it was validated by insights from the campaign analyst interviews. The result was a four-phase impact matrix, with each enhancement assigned a placement supported by a clear rationale.

Once the initial matrix was created, I met with the backend team to align on data availability for the proposed features and to understand what had already been built in previous attempts, as well as the issues they had encountered. With that context, I brought the matrix into a working session with the campaign analysts and stakeholders, where we reviewed the feature placements and validated the project scope.

From this working session, I was able to outline what would be required in the product for the first phase:

  • Auto-parsing segment names: Segment names already encoded all the information that analysts were manually entering during Stage 3, eliminating the need for manual input.
  • Pre-calculated statistical significance: Standardizes the analysis process across the team.
  • Three-tab architecture: Discovery identified three distinct workflow patterns. Separating them into three tabs allows each workflow to evolve independently without compromising user needs.
  • Single consolidated table instead of KPI cards: Enables full-page PDF and Excel exports that match the existing report format, making the experience familiar to users and reducing training requirements.
  • Radio buttons for segment filtering: Keeps the view focused and easy to scan. Multi-select filtering would create excessive horizontal scrolling and may not be feasible in Phase 1.
  • Visual hierarchy: Prioritizes the most-viewed metrics by making them the most prominent.
  • AI Insights: Integrates Copilot to automate the commentary process, eliminating the hours previously spent writing it manually.

Other enhancements were deferred to ensure the delivery timeline was met.

Information Architecture

With the scope for the first phase agreed upon, I translated the features into an information architecture that also served as a future-state workflow map. While the current process spanned seven to eight separate Excel sheets, the information architecture consolidated the workflow into three views: Campaign Analysis, Daily Tracking, and Quarterly Review. A single segment filter would be applied across all views simultaneously, replacing the duplicated per-tab filtering that was the primary pain point in Stage 4.

As the information architecture took shape, one issue became clear: every metric existed at the same visual level, with no indication of which metrics drove decisions and which served as supporting information. I held a working session with the analysts and stakeholders to establish a logical hierarchy.

The session resulted in a three-tier grouping of key, secondary, and supporting metrics. This became the primary visual hierarchy across every view, with the specific metrics changing based on the use case.

Design Requirements

Since the company had already developed several Power BI dashboards for other use cases, I was given the opportunity to review active tools currently in use. Two key decisions shaped my approach early in the design process:

  1. Maintain an iterative design approach: Split the design process into two stages: low-fidelity and high-fidelity wireframing. Before introducing visual design, I wanted to validate the content, layout, and overall structure of each screen. Beginning with low-fidelity wireframes made it easier to gather feedback, iterate quickly, and avoid unnecessary rework later.
  2. Develop a transferable design system: Related workstreams were developing their own visual language independently, with no shared foundation between them. As a result, analysts moving between tools encountered different color conventions, spacing, and component patterns.

With these principles established, I began creating low-fidelity wireframes for the three primary views: Campaign Analysis, Daily Tracking, and Quarterly Review.

Insights from the feature prioritization and information architecture workshops made it clear that analysts expected an experience that felt familiar while improving the workflow. That meant maintaining the tabular format, keeping metadata and key metrics on a single screen, and surfacing statistical significance instead of burying it within the report.

Testing

The low-fidelity wireframes replicated the look and feel of existing Power BI screens, providing users with a familiar framework to review without introducing visual design decisions too early. At this stage, the focus of the review was to validate whether the information architecture, content, and layout effectively supported the use case.

I tested the low-fidelity wireframes with the two campaign analysts. After walking through the wireframes, only one key piece of feedback emerged: the metrics within the table needed to be reorganized.

Through a quick brainstorming session, we identified the best order for presenting the metrics to create a more logical story and improve how users consumed the information. With this refinement incorporated and approved, I moved into developing the design system and high-fidelity wireframes.

Design System

The company had been developing dashboards without a consistent visual language, resulting in varying design patterns, component styles, and user experiences across different tools. Rather than creating another solution that contributed to this inconsistency, I established a foundational design system that could be adopted and expanded by future projects.

The process began by reviewing existing Power BI dashboards to identify common patterns, reusable components, and areas of inconsistency. From there, I defined the core building blocks of the system, including color conventions, typography, spacing guidelines, grid structures, component behaviors, and interaction patterns. These elements were documented and translated into reusable components that could support consistency across future dashboard experiences while still allowing flexibility for different use cases.

By creating this foundation before moving into high-fidelity designs, the dashboard could align with a broader visual language rather than becoming another standalone solution.

Finalized Design

Once the design system was completed, I was able to finalize the high-fidelity designs and apply a consistent visual language across the experience. The final solution was structured around three primary tabs, each supporting a distinct part of the campaign analysis workflow:

  • Campaign Overview: The primary working view that brings together campaign metadata, KPI cards, and detailed metric tables with segment-level breakdowns. This view is designed for day-to-day analysis, allowing users to quickly understand campaign performance and identify areas requiring further investigation. Users can filter data at the grain of Brand × Campaign × Segment 1 × Segment 2.
  • Daily Summary: A deeper analysis view focused on performance trends throughout the campaign window. This view supports investigation when anomalies are identified in the Campaign Overview by helping analysts pinpoint which specific days contributed to unusual results. Users can filter data at the grain of Brand × Campaign × Date Range × Channel × Treatment Code × View.
  • Quarterly Review: A leadership-focused summary view that aggregates campaign performance across multiple campaigns and campaign types. This view provides a higher-level perspective on trends, outcomes, and overall performance. Users can filter data at the grain of Brand × Year × Quarter × Campaign Type × Segment 1.

Together, the three views transformed a fragmented Excel-based workflow into a more structured experience, allowing users to move from detailed campaign analysis to broader performance reporting within a single platform.