Reporting Rebuild

Act 1 — The Bet

Biggest accounts were churning over Integrate's reporting feature. The work was to overhaul it end-to-end — replace the legacy report runner with a configurable surface customers could actually navigate, before patience ran out completely. The cost was that the rebuild had to ship in pieces against an active product, with no quarter to take the feature offline, and through a mid-project PM handoff.

The signal that crystallized the priority came from a customer:

"We have a machine called 'The Beast.' We brought it in specifically to run reports from Integrate." — HiP

Customers were buying hardware to outrun our software. The number wasn't abstract.

Act 2 — Constraints & Cost

The reports feature wasn't built to scale, and Integrate was scaling. The pain wasn't localized: Finance used reporting for billing and couldn't get it to perform, Managed Services ran the platform on behalf of customers and lived inside the same suffering, and Product had to look at the surface constantly for design work. Every internal function that touched it was carrying the cost.

The UX failures compounded the technical ones. The Reports Settings page — where most of the actual report-building happened — had no procedural cues, an unreliable search, all the important controls below the fold, and infinite scroll where the new data lived at the bottom of the list. The most-seen state was a spinning loading logo. The Fields tab let users build custom data rules in liquid markup, but the only place to write them was a tiny text input that couldn't show a page-long string at a glance. The Schedules tab tucked its actual controls into a modal and rendered an email body where the schedule should have been.

Legacy Reports Settings page — a cramped form layout with Settings, Fields, Schedules tabs at the top, a flat list of source rows below, and no procedural cues about what to do first — The legacy surface, by failure mode. The Reports Settings page where you couldn't tell what to do next; the spinner that was the most-seen state; the Fields tab where page-long liquid expressions had to live inside a one-line input; the Schedules tab whose actual controls were tucked behind a modal.

Reports Settings page covered by a three-circle spinner loading overlay — the most-seen state for users running larger reports — The legacy surface, by failure mode. The Reports Settings page where you couldn't tell what to do next; the spinner that was the most-seen state; the Fields tab where page-long liquid expressions had to live inside a one-line input; the Schedules tab whose actual controls were tucked behind a modal.

A previous rushed effort to relieve pressure had introduced a feature called Auto-add — pick a campaign, media partner, or account, and new sources would automatically attach to a report. Useful in principle, but it had shipped to satisfy a single customer, no one inside the company knew it existed, and now it had to coexist with the redesigned settings flow without making the surface more confusing than it already was.

Mid-project, my product manager left. The new PM asked the obvious question — where's the validation data? — and the honest answer was that the previous round of decisions had been made before any was collected. We re-validated the whole thing. Worth it; a lot of the original choices turned out to be wrong.

Act 3 — Decisions & Tradeoffs

Source as the navigational pivot

Everyone on Managed Services already thought about reports in terms of three pivots: the marketer, the media partner, or the campaign. The shared concept underneath all three was the source — the partnership between a buyer (the marketer) and a seller (the media partner). The first decision was to make the source the navigational component of the new surface, with the three pivots as filter axes rather than separate views. The tradeoff was a steeper mental on-ramp for one-off users; the offset was that the people running reports daily got the model they were already using in their head.

Whiteboard sketch from the discovery phase — 'Campaign / Source / Marketer / Media Partner' bullets on the left, 'BUYER ↔ SELLER' annotation at top, and rough UI wireframes below showing a sidebar-plus-content layout — The whiteboard moment the Source component came out of. Buyer ↔ Seller as the underlying concept; the three pivot points (campaign, marketer, media partner) as the views customers actually used to find them.

Diagram of the Source component — a central blue Source node connected via dashed lines to three labeled boxes: Campaign, Marketer, Media Partner — The pivot, formalized. Source at the center; campaign, marketer, and media partner as the axes you filter against. One component replaced three parallel ways of navigating.

E-commerce as the mental model

The hardest part of the rebuild wasn't the data — it was the filter UI. Filters that looked too much like the table data created confusion at a subconscious level; the gestalt cue was off, and users couldn't tell where the controls ended and the content began. The pattern was breaking the mental model the rest of the page was trying to establish.

The unlock came from looking outside B2B reporting. E-commerce had solved this exact problem at scale — massive product catalogs filtered, sorted, and selected by people who never read documentation.

The pattern source. Millions of people filter, sort, and select against massive catalogs every day on Amazon without thinking about it. That mental model was the reference.

The components transferred directly:

Filters on the left, distinct in shape and weight from the content
Content on the right, free to render however the data warranted
Aggregated total on top so the filter state stayed legible
An at-a-glance summary of what had been filtered out

Wireframe of the e-commerce layout pattern — a narrow filter column on the left with stacked filter cells, a content area on the right with a row of filter chips at the top followed by a stack of result rows — The e-commerce pattern in wireframe. Filters left, content right, filter chips on top, rows of result content below. Recognizable to anyone who has ever shopped online; rare in B2B SaaS at the time.

That pattern wasn't typical in B2B SaaS at the time. The cost was arguing for it past stakeholders who didn't recognize the precedent; the offset was a navigation model every user already had in their head from buying things online.

Collapsible drawer for Auto-add — proved with an A/B test

The disagreement that took longest to resolve was about Auto-add. My PM wanted it broken into a separate flow — a modal. I argued for keeping it inside the same surface, since the function lived in the same data space as filtering. We couldn't reach agreement, so we ran an A/B test.

The original Auto-add feature — a separate set of toggles per campaign, media partner, and account, with no clear relationship to the filter or report-source flow — Auto-add as it shipped originally — a disconnected toggle set with no clear relationship to the filter or report-source flow. The A/B test asked whether to embrace that disconnection or close it.

The modal lost. Users rated the interruption-of-flow as the worst part of the experience, and the modal felt out-of-place against the e-commerce pattern the rest of the page had committed to. The shipped design tucked Auto-add and filtering into a shared collapsible drawer, triggered from two distinct buttons — same pattern, separate actions, mutually exclusive use. That preserved the mental model while keeping both functions reachable.

The shipped Reports Selection tab — Filter / Auto-add / Settings buttons at the top of the canvas, the Auto-add drawer expanded on the left showing a searchable Campaigns list with toggles, and the sources table rendered on the right — The shipped solution. Filter and Auto-add share the drawer position; the buttons toggle which one occupies it. Same UI component, two functions, no modal.

Validate before build

The new PM's arrival reset the cadence. From that point every design decision had a usability-test result behind it before it reached development. Five recurring collaborators from Managed Services ran the same flows repeatedly against each iteration — slow at first, fast once the pattern stabilized. The cost was timeline; the offset was that nothing built had to be re-built after launch.

Act 4 — Outcome

The rebuild shipped in pieces — one tab at a time, against the live product, behind feature flags where it made sense.

Customers got hours of their week back. Reports that had been the reason customers brought hardware in-house started running inside the platform again. The Beast anecdote stopped being a recurring joke.
The pain stopped routing around the tool. Finance, Managed Services, and Product — the three internal functions whose work had been deformed by the legacy surface — could use reporting as designed instead of working around it.

The rebuilt Reports summary view — a clean browsable index of disparate report types collected into one searchable surface, with filter and sort controls — The summary view that replaced 'which report do I run today?' with a browsable index. The first surface to land on the new pattern, and the one that set the read for everything that followed.

Before and after of the Integrate reporting surface — legacy report runner replaced by the configurable dashboard — The reporting surface, before and after. Same data, different relationship between the customer and the tool.

Act 5 — Reflection

The lesson from Shopping for Data was where to look for patterns. The reporting surface didn't get solved by studying B2B reporting tools; those tools had the same problems we did. It got solved by studying e-commerce, where the underlying user problem — navigate a large set of items, filter to what matters, take action — had been solved well enough that millions of people did it daily without thinking. Pattern transfer across domains was the load- bearing move.

The other lesson was operational. The PM-handoff moment, where the new PM asked for the validation data and there wasn't any, was a small disaster I should have prevented. Decisions stored only in your own head don't survive the team change. From that project on, validation evidence went into a shared place at the time of the decision, not retroactively when someone asked for it.