The Modular
Report System

Overview
Liberu is a full-service influencer marketing agency: it runs campaigns end to end, from creator sourcing to performance measurement. To operate at that scale without growing headcount with every new client, it built its own internal platform. Two years ago, that platform introduced a module that generated campaign reports with AI. Over time, Liberu moved away from standardized packages and started designing increasingly sophisticated, tailor-made campaigns, and the module, built for a different kind of campaign, couldn’t keep up. I designed the Modular Report System: a catalog of AI-powered pieces that activate based on what each campaign needs, built to grow with the business without being rebuilt every time.
Client:
Liberu
Year:
2026
Category:
Product Design
/
Product Strategy
Location:
Mexico City

✦ My Role
I led the project end to end: research, strategy, and high-fidelity prototypes of the entire system, which we used to validate the idea with the team. I then developed the final interface together with a UI designer, under my direction.
✦ The Challenge
The reporting module promised AI-generated results in minutes. In practice, the team had stopped using it.
It didn’t happen overnight. The team started noticing the data wasn’t reliable, and double-checking it externally became more work than building the report manually from scratch.
“I don’t trust the results the platform gives me, and in the end I always have to check everything externally — so instead of making the work easier, it makes it more complicated.”
The real cost wasn’t just time, it was capacity. Liberu runs around 17 to 20 campaigns a month, each needing at least two reports, and all of that falls on a single person: a tracking report takes about a day, a results report 3 to 4 days, and a postmortem up to two weeks. The math didn’t work. The workload exceeded what one person could handle, so reports were delivered late or cut short. The module meant to free up capacity had become the bottleneck.
It was a commercial problem too. The accounts team knew that selling AI-powered, automated reports was a strong hook for clients, and also knew the operation behind it couldn’t back it up.
“The feature, as a concept, is a hook for the clients, but we know that in reality, it’s not like that.”
Underneath that abandonment were four concrete problems:
Outdated structure: the report was missing entire sections the business already needed.
Generic, repetitive analysis: rebuilt by hand for every campaign, with nothing learned from the last one.
Analysis based only on metrics, almost never on the content itself: the video analysis tool was slow and unstable for large campaigns.
Unreliable sentiment: it didn’t use the right parameters to interpret comments.
None of the four was the problem on its own. Together, they had eroded trust to the point where the team preferred not to use the tool at all, and fixing them one by one was never going to win it back.
✦ My Approach
The initial ask was narrow: the AI analysis wasn’t good enough, so the obvious fix was better prompts. I started there, but the deeper I looked, the less that explained what was actually broken.
I interviewed five people involved in reporting, two from the team that builds the reports and three from sales and accounts, because each group experienced the same report from a completely different angle. I sat with the reports team as they worked, to see how a report actually got built instead of just asking them to describe it. And we audited over 15 past reports, looking for patterns nobody had written down.
What I found wasn’t just bad AI output. It was that “the report” was never really one thing. Depending on where a client stood, the team was building three different documents under the same name: a lightweight Tracking report to justify in-flight decisions on an active campaign, an Active Client report with deeper analysis to close out a renewing contract, and a persuasive Postmortem to reopen the conversation with a client who no longer had a campaign. Nobody had ever named these as different report types; they were built from instinct, case by case.
My proposal was the Modular Report System: instead of a report with a fixed structure, a catalog of pieces (Executive Summary, Winning Content Anatomy, Platform Performance, among others) combined based on what each report needs to accomplish. Like Lego: the catalog is the same for everyone, but what you build depends on what you’re trying to solve.


At first, I assigned a fixed set of pieces to each report type. The team made me see it was the same rigidity, just split into three boxes. So I changed it: each type starts with default pieces, but any of them can be turned on or off.
Building the full catalog required time from a team that was already at capacity, so before asking for it, I needed to know the idea held up. We broke down existing reports to define the pieces, and I asked the reports team to build a real report using only those pieces. It worked, and the test did double duty: it confirmed modularity was viable and showed exactly what content and logic each piece needed to carry.
With that validated, I designed the system to be living: the catalog can grow with new pieces without touching or re-releasing anything that already exists. That directly answers why the previous module failed. It wasn’t poorly built, but the business kept changing shape, and every change meant rebuilding from scratch. The goal wasn’t just to solve today’s problems, but to make the next shift in the business cheap to absorb.
Building the full catalog meant real time from a team that was already at full capacity, so before asking for that commitment, I needed to know the idea actually held up. I broke down existing reports to define the catalog of pieces. With that catalog in place, I asked the reports team to try building a real report using only those pieces, nothing else. It worked — and that test did double duty: it confirmed modularity was viable, and it showed me exactly what content and logic each piece needed to carry.
With that validated, I designed the system to be living: the catalog can grow with new pieces without touching or re-releasing anything that already exists. That directly answered why the previous module had failed — not because it was poorly built, but because the business it served kept changing shape and the module couldn't keep up; every shift meant rebuilding from zero. The goal wasn't just to solve today's five problems. It was to make the next shift in the business cheap to absorb, instead of another full rebuild two years from now.

Building on the validation prototypes, we developed the final interface together with a UI designer, under my direction. The system addresses what had broken trust in the previous module:
Verifiable data: every metric shows when it was last updated, and sentiment can be checked against the actual comments.
Content analysis, not just metrics: the AI analyzes each post and explains why it worked, not just how far it reached.
AI proposes, people decide: the analysis arrives as an editable draft, and the team refines it before it reaches the client.
Client-ready: brand settings (logo, colors, and typography) are saved per client, so every new report starts on-brand.
The Result
The team trusts the tool again. Around 20% of reports still get final edits outside the platform, and that’s by design: a new piece only enters the catalog when a need repeats across clients, never for a one-off. Six weeks in, that process has already surfaced the first one: Category Performance. The time freed up now goes into strategic work, like writing more creative briefs that shape campaign performance from the start.







