01 · Product design

From four products to one unified experience

Audience Intelligence App. Every Audiense customer now starts in one place, and a new account gets to its first report in under a day instead of three.

Role
Design lead of a cross-functional task force
Team
2 designers, 1 PM, 1 tech lead, 7 engineers
Timeline
Jan 2025 – Feb 2026, shipped in 4 releases
Scope
4 products, 1 shell, 1 report model
Separate apps merged into one product and one login
4 → 1
Separate apps merged into one product and one login
Days to first report for a new account (median)
3.2 → 0.9
Days to first report for a new account (median)
New reports that combine two or more channels
6% → 27%
New reports that combine two or more channels
Navigation and "where is my report" support tickets
−38%
Navigation and "where is my report" support tickets

Source: Mixpanel product analytics, comparing new accounts and new reports from the year before the project with those after the last release in Feb 2026. Support tickets by tag, quarter over quarter.

The problem

Audiense had grown into four products: two built in-house and two that came with acquisitions. Each one had its own name, navigation, and report format. They shared data underneath, but a customer could not see what one product held, so the work stopped at the edge of each app.

The cost showed up everywhere. Sales pitched four products with overlapping names. Support answered the same "where is my report" question every week. Only 6% of new reports combined more than one channel, which is exactly the analysis our biggest customers pay for.

The bet

Not a rebrand and not a big-bang rewrite. One shell first, so every product lives behind the same front door, then one report model, so results can be combined. Each release had to be useful on its own, and nothing could break for the accounts already paying.

Key decisions

1. One front door, not a product switcher

The first proposal from the business was a switcher in the header. I pushed back: it would have kept four products and added a menu. Instead, the app starts by asking what you want to explore, then picks the right report for it. Product names disappear from the main path. In testing with 12 customers, 10 created the right report type on the first try, against 4 of 12 with the switcher prototype.

The start of the app. Ask what to explore, then add a report.
The start of the app. You say what to explore; the app chooses the report. Customer data replaced.

2. One report model, so results can be combined

Every report, from any source, now has the same anatomy: source, method, audience size, then summary, channels, countries, and trends. That constraint was the hardest negotiation of the project, because two teams had to give up custom layouts. It is also what made cross-channel reports go from 6% to 27%.

Every report in one list.
One report list for every source. Source, method, and audience size, always in the same place.
One report. Summary, channels, countries, and trends in the same place.
One report anatomy. Summary, channels, countries, and trends together.

3. Ship in slices, then add the copilot

Four releases over thirteen months, each one useful without the next. The copilot came last on purpose: an assistant needs one consistent report model to read, and before the unification there were four.

  1. Mar 2025The shell. One login, one navigation, every existing product inside it.
  2. Jun 2025One report list across sources, with the same source, method, and size columns.
  3. Oct 2025Digital intelligence for Meta and LinkedIn, rebuilt inside the app instead of next to it.
  4. Feb 2026The AI copilot, which works because there is now one report model to read.
Digital intelligence for Meta, in the same app.
Digital intelligence for Meta, rebuilt inside the app in 7 weeks.

What stayed out, and why

Saying no was part of the design. Two products did not move in.

Social listening for X

Different users, different job. Merging it would have added a mode switch for 9% of accounts and confused the rest.

Audience intelligence for X and TikTok

It stays on its own stack until the data pipeline is shared. We designed the slot for it, so it arrives as one more source, not a fifth app.

Results

Adoption

Weekly active accounts using more than one data source went from 14% to 41% in the six months after the report list shipped.

Sales

One product to demo instead of four. The standard demo went from 45 to 25 minutes, and sales stopped needing a slide to explain product names.

Support

Tickets tagged navigation or "can't find report" dropped 38% quarter over quarter after the shell shipped.

Delivery

Three front ends became one, built on the design system. New report types ship as a template, not a project: the Meta rebuild took 7 weeks against a 4-month estimate.

What I did

  • Information architecture and navigation for the whole suite
  • The shell, its empty, loading, error, and permission states
  • The rollout plan: which product moves in first, and what stays out
  • Weekly design review with the task force and the CPO

What the team did

  • Report pages and the summary view: a product designer on the team
  • Data model and migration: the tech lead and backend engineers
  • Pricing and packaging for the unified product: product and sales