Custom Reports in Predict

When I joined the Predict team, I was handed a small ClickUp ticket: let users duplicate a widget so they don’t rebuild the same configuration over and over. Estimate: one to two days.

Working the flow, I realized duplication treated a symptom. People cloned widgets because building and editing reports was slow, confusing, and inflexible. Instead of stopping at the ticket, I started pulling on the thread behind it.

Our team was reading Continuous Discovery Habits in book club, and I was running weekly discovery interviews with Predict users. Reporting workarounds kept surfacing in otherwise unrelated conversations — over 50 interviews across the internship, plus a focused session with four UK brand managers who had tried the original tool and walked away.

Pendo told the other half of the story. Roughly 60% of eligible users had created at least one Custom Report in the feature’s first year — strong demand. Only about 15% ever came back, against enterprise retention benchmarks around 28–35%. This wasn’t a discovery problem or a demand problem. It was a usability problem.

Custom Reports had to serve two internal roles with different jobs and the same workaround. I built a persona for each from the interviews:

Three hard limits shaped every decision. I couldn’t introduce new data sources — missing forecast, wholesale, and logistics metrics were platform gaps I could only document and escalate. I was bound to Predict’s existing design system and component library. And engineering had capacity for a slice of the redesign, not all of it — so the scope became the smallest set of high-impact changes that could realistically ship.

The sharpest cut was the drag-and-drop builder. A canvas where you drag metrics, layer dimensions, and build pivot-style reports matched advanced users’ mental models — and exceeded the engineering budget. I presented the user evidence and the trade-offs, leadership made the call, and my job became preserving the value — flexible report construction — inside a structured flow that could actually ship. Drag-and-drop went to the roadmap; so did per-brand report theming, which brands kept asking for.

With poor retention, most returning users were effectively beginners every time they opened the tool — so the redesign attacks the cold start first. The home screen leads with templates and a tile grid that previews every report. A large New Report button opens a guided modal flow that gathers just enough — name, scope, first widget — to land you in a working report, and a first-run wizard explains the toggles, settings, and timeframes that used to be opaque.

Inside a report, the view/edit split is gone — one mode serves both presenting and editing, with actions in context. Filters became clearer and editable after creation instead of locked in. And widgets finally reorder: a Widget Order list in the report settings with drag handles — the feasible version of reordering, shipped while the full canvas drag-and-drop waited on the roadmap.

Charts broke the two-metric cap: multi-metric comparison, the single most requested capability, became the core of the in-report experience. Reports gained share and export, plus scheduled email sending, so the weekly client report could leave Predict without a screenshot. And because so much sharing happens asynchronously, a widget can now carry a note — the context a manager would otherwise write in the email next to a pasted screenshot travels with the chart itself.

The people this tool was for sat in the same office, so I tested with them directly: twenty live usability sessions — ten brand managers, ten ad strategists — on the redesigned flows.

I assumed people wanted a clean separation between viewing a report and editing it. Watching them work killed that: managers present reports live and edit the graphs on the fly, with the client in the room. A separate edit mode was friction in the exact moment the tool had to shine. The shipped design uses one combined mode.

Filters were the other reversal. In the old tool, the filters you chose at creation were permanent, and they silently constrained which metrics and charts you could build — users never understood why things wouldn’t work. The redesign makes filter setup informed up front, and filters editable after the report exists.

The Templates feature needed starting points that reflected real reporting work, not a designer’s guess at it. So I ran a report-building competition across the brand managers and ad strategists — prizes included — to see who could build the best reports in the new system. The winning reports became the shipped templates, and the contest doubled as another round of honest feedback from the tool’s toughest audience.

My internship ended before the rebuild reached production, so I’m careful about what I claim. The redesign was validated through usability testing and shipped by the team after my internship — the post-launch numbers belong to them.

My first instinct was wrong. Every user I interviewed had a different power request, each vital to their own workflow, and early on I believed building all of it would make the perfect tool. It would have made a slow, overbearing one — and an unbuildable one. The discipline of the project was separating the biggest lifts that helped every user from the requests that helped one, and protecting a simple core experience, because complexity was the original product’s actual failure.

This project also rewired what I think my job is. I don’t wait for a defined problem anymore — I watch for friction, ask why it exists, and turn it into something worth investigating. The ticket is the symptom; the workflow around it is the problem. And a design that ships beats a design that impresses: pressure-test what users actually need to decide before polishing the interface they decide it on.

With more time, I’d have built custom brand themes for reports — brands loved seeing their own colors in client decks, and it was cut purely for roadmap capacity.