The report that couldn't explain itself

Overview

Role

Product designer on the project. Discovery, state model, interaction design, interface, prototype. Project led by our lead product designer.

Timeframe

February – July 2026

Surface

Report landing page, report builder, module system, sharing, permissions

Team

Stefano D’Avascio (design lead) · Thomas Boyd (frontend) · Leo Pavithran Sundar and Jonathan Raya Rios (backend) · product and customer success

Status

Facebook and TikTok built and in internal testing. Paused before external beta.

The message

In 2022 a customer wrote to her account manager about our reporting. She wasn’t angry. That’s what made it land.

“I would prefer to stay with Sendible — the price point is perfect and the interface is much easier to manage. But I have not felt much confidence in the reports we’ve been trying to generate lately. Are there plans to change or update how reporting is done?”

Four years later I was asked to answer that question.

By the time I picked it up, the same note was arriving from three directions at once.

A customer who scored us zero on NPS wrote that reporting wasn’t what she needed to manage anything at scale. Her account manager added the part that mattered: not flexible enough, and the date ranges too short to see one year against another.

A trialist with fifteen years in social marketing signed up on a lower plan than we’d expected, and told us why — she’d seen numbers in reporting she didn’t believe.

And a customer who had bought a larger package specifically to get custom reporting called it clunky and slow, then went to Meta’s own dashboard to do the job herself. She’s since been asked to research replacement platforms for 2027.

Nobody was describing a missing feature. They were describing a product they’d stopped believing.

Why belief had gone

Reporting had grown into two systems that didn’t know about each other. Quick reports were fixed and network-specific. Custom reports were flexible but built on foundations that couldn’t take any more weight. Every new network meant building the same thing twice.

The seams showed up as small bugs that customers read as lies. A report claiming four Facebook posts in a month when there had been many more. A date filter set to February still drawing its comparison from January. Engagement climbing month on month while the arrow beside it pointed down. Exports breaking when a report title ran long, or returning five metrics for one page and seventeen for another.

None of those are hard problems on their own. Together they teach someone that the number on the screen might not be true — and once that’s learned, no individual fix un-teaches it.

What I went and found

I was handed reporting, navigation and workspaces in February, along with a conceptual prototype and a brief to come back with flows and hypotheses.

I went and talked to people instead.

Over three weeks I sat down with the three functions that absorb the consequences of reporting nobody trusts. Customer success, on white-label reporting, which surfaced that customers couldn’t compare anything beyond ninety days — a limit that quietly makes year-on-year reporting impossible. Onboarding, on what new customers arrive expecting, which turned out to be high standards on both how a report looks and what it contains. Support, on what comes back repeatedly: missing post-level metrics, inflexible date ranges, no way to compare one period against another, and a genuinely painful experience for anyone managing multiple locations.

Then I asked for light-agent access to the support desk, so I could read what customers actually wrote rather than a summary of it.

Every quote in the section above came from that fortnight. None of it was in the brief.

Before the screens

The thing that had cost us customers wasn’t an absent feature. It was a report that showed something wrong and said nothing about it.

So I started with behaviour rather than layout, and specified the system’s states before drawing a single module. Seven states for a report — draft, configuring, ready, collecting data, partial data, disconnected, error. Six for a module. Then every journey written as preconditions, action, and the state change that results.

One recommendation mattered more than all the others: “No Data” had to carry a machine-readable reason.

Not an empty panel. A state the interface can explain and an export can reflect. A module that’s blank because a profile lost its connection is a completely different problem from a module that’s blank because nothing happened that week — and a customer who can’t tell those apart learns to distrust both.

In design review I put it as plainly as I could: the error state has to say what is wrong and how to fix it, and it has to do that most clearly at the moment a module loses its data source.

The note from that meeting recorded that I’d be defining the states and redefining the whole interface and interaction model.

I then named every screen against the same structure the requirements used: permission states, list states, interaction states. Engineering could implement against a complete set rather than a happy path.

Two rules

Everything after this came out of two rules that look like opposites and aren’t.

Never hide capability. Name the barrier.

A template you can’t use stays on screen. If the network isn’t connected, the card says Connect profile. If it needs a higher plan, the card says Premium.

Hiding either would have made the product look smaller than it is and left the customer with nothing to do about it. It’s the same instinct as the “No Data” reason, moved one level up: don’t remove the thing, explain what stands between the person and it.

Show only what this decision needs.

The template cards briefly carried a module count, telling you how many modules you’d get. I liked it. I took it out.

The test we used was whether something served the decision in front of the user. Premium and Connect profile are barriers you need before choosing. A module count is detail you want after choosing. One belongs on the card, the other belongs on the next screen.

Both rules come from the same place. One adds information and one removes it, and what decides is whether the person needs it yet.

The panel

The template panel had a problem that gets worse with time. Every network we support adds a card, and a panel can’t grow forever.

The first versions went for presence — six cards running edge to edge, wider than the container they sat in. Cutting to four fixed the layout and raised a fair objection: if your network isn’t on screen, is it supported? So I tried the opposite, put all nine on the page, and watched the panel swallow the entire first screen. Anyone returning to find a report they’d made last week now had to scroll past a wall of templates they’d already chosen from.

What shipped stops treating it as a choice. Four cards stay visible, the rest sit one control away, and every card names its own barrier. The smaller set ended up carrying more information than the larger one had.

The list

The list of existing reports started as a table with its own furniture: filter tabs, a search field, a grid and list toggle. All of it built for this page.

What shipped threw all three away and used the filter component that already existed elsewhere in the product. Sortable columns. Network icons in a column of their own, so you can see what platforms a report covers before you read its name.

Reusing a component someone else had already built was the better design decision and also the cheaper one. Those don’t always land together, and when they do it’s worth saying so out loud rather than pretending the choice was harder than it was.

The notice

Telling someone whether they’re viewing a report or editing it took nine iterations.

Every one of them was a different arrangement of the same thing: a text banner saying which mode you were in. Short, then long, then short again, then gone entirely. I kept adjusting the sentence, its placement, its weight.

The version that shipped has no notice at all. The header simply fills with colour when the report becomes editable.

Five layouts, then colour. The problem was never that the notice was the wrong size. It was that a notice was the wrong instrument — I’d spent nine iterations refining an answer instead of questioning the question.

There’s a second decision inside that one. View mode isn’t a separate screen — it’s the same screen with about a dozen elements switched off. The rail, the module panel, the action buttons. Same objects, different visibility.

That’s what stops two modes drifting apart during build, and it’s what made the cut-down version possible later.

Building it

I built a working prototype in code rather than a clickable file: a report hub with seven templates, the reports list, the module library and a live canvas.

The product decisions, the state model, the interaction design and the interface were mine. Claude Code was a fast pair of hands that let me put something in front of the team they could actually use. Grid behaviour, module resizing and drag-and-drop are the kind of thing you can’t evaluate by looking — you have to move something and see what happens to everything else.

Working alongside frontend and backend we settled architecture as we went. Social icons served from the design system rather than stored in the backend. Date ranges saved as rolling periods rather than fixed dates, so a report shared in March doesn’t quietly become wrong in April. Profile IDs stored per report.

Facebook and TikTok were built. Nineteen TikTok modules reached the front end in early July, and the work moved into internal testing.

Cutting it down

The design assumed nine networks. The first release supported two.

The easy version of that is to ship the nine-network layout with seven cards missing. I re-proportioned the row so three cards fill it completely, removed the expand control that would have promised templates nobody could reach, and brought start from scratch back into the card set to keep the row balanced — reversing my own earlier decision, because that decision was right for a page with nine options and wrong for a page with two.

A first release should look finished, not like a full product with the parts not yet delivered.

What it was for

There’s no launch metric on this one. What there is instead is a fairly precise picture of what reporting was costing, drawn from the same sources the design came from.

Retention. Reporting was named in NPS detractor responses, in a churn survey, and by an account now formally evaluating replacements for 2027. These weren’t customers who disliked the product — two of them said the opposite in the same breath. Reporting was the single thing pulling them out.

Expansion. One customer bought a larger package specifically to get custom reporting, didn’t get what she needed, and went to a competitor’s free dashboard instead. Reporting was already an upgrade trigger; it just wasn’t holding the customers it attracted.

Trials that convert lower than they should. A trialist with fifteen years of experience chose a smaller plan because she didn’t trust the numbers she saw. Reporting was affecting plan choice at the point of purchase, before anyone had spoken to sales.

Support load. The recurring ticket categories were all reporting: export formatting, metric inconsistency between networks, date filters, retention limits, profile caps. Each of those is a system problem being handled one conversation at a time.

Demand, sized. The first project alone carried 29 customers and 13 project-level requests before anything was designed.

Pricing. The business intended to position the new reporting as a value-added feature supporting a price increase. That only works if the thing is trusted, which is the whole argument of this project in one sentence.

So the target wasn’t a conversion rate. It was the moment a customer opens a report, sees a number they weren’t expecting, and has to decide whether to believe it. Everything in the state model exists to make that moment recoverable — to give the interface something honest to say when it can’t say what the customer hoped.

Where it stands

In July the company changed how projects get approved: every initiative now needs a cost-benefit case, a one-month delivery window, and a clear path to being sold as an add-on. A six-month rebuild doesn’t fit that shape, and Reporting 2.0 was paused with Facebook and TikTok built and in internal testing.

The same decision recorded that legacy reports will still be replaced with these designs, positioned as the value-added feature. The timeline changed. The plan didn’t.

What I’d carry into the next version of it: the state model. Modules will change, networks will come and go, the layout will be redrawn by someone else eventually. The question of what a report should say when it has nothing to say won’t change at all, and it’s the question that started this.