Case study · Shipped, in production
AI Report: Rebuilding a 20-section report around what analysts actually read
Sole designer, end to end. Research, concept, 8-week proof of concept, shipped product. One year in, it gets 2.5x the usage of the legacy format it reimagined.
My role & the room
Role: Sole product designer. Research, concepting, UI, prototyping, front-end collaboration.
Team: a product manager, a project manager, an engineering lead, and two engineers
Timeline: kicked off February 2025 → 8-week proof of concept → green light → 3-month build → shipped summer 2025
2.5x
analysts request the AI-native report two and a half times more than the legacy format, one year post-launch
10+ min → <60 sec
generation time
The brief vs. the problem
The brief was to make our flagship report cheaper to produce. The real problem was the format. Fifteen to twenty data-dense sections made every report expensive to build, expensive to sell, and skimmed in practice. Analysts weren’t asking for more sections. They were asking one question: what do I need to know about this entity right now? Cutting production cost without changing the format would have made a cheaper version of the wrong thing.
The constraint that shaped everything
Trust. An AI-generated summary in an intelligence product fails differently than a slow report does. It fails confidently. Every design decision routed through one question: can the analyst see where this came from and verify it in one step?
Process
Four focus groups with analysts, plus ongoing conversations with sales and internal stakeholders, to map how the legacy report was actually read, and which sections never were. The finding: of fifteen to twenty sections, most analysts used three to five. The rest was noise they scrolled past.
From there, two questions shaped the concept: which sections were analysts actually going to, and what use cases and questions were they trying to get answered
Synthesis into divergent concept directions, sketched and pressure-tested before committing
8-week proof of concept, designed and built in parallel with engineering. The goal was proving feasibility, not just desirability.
Green light → three-month build → ship
[IMAGE SLOT]
Early sketches — caption with the decision it shows
[IMAGE SLOT]
A direction we discarded and why it lost — caption with the decision it shows
[IMAGE SLOT]
Final UI — caption with the decision it shows
The directions that lost
We concepted wide before committing. Mad Lib-style prompt builders. Filter-first approaches where you assembled the report by narrowing it down. Progressive reveals where content stayed gated until you’d made certain choices. Each one went in front of management and real users.
They lost for the same reason: they made the analyst do the configuring, and none of them adapted to both the entity and the question at once. The direction that won came straight out of the research — analysts kept asking the same consistent questions, so we built the report as cards that populate around those questions, most relevant first.
The design
The top third of every report holds steady: identity, structure, orientation. Below it, the cards adapt. A shell company and a multinational don’t get the same report, and neither do two different questions about the same entity. The layout responds to what you asked and what you’re looking at.
In practice: you request a report on an entity with an initial question preselected. Once you’re in, you can change the question and the page rebuilds around it — the takeaway box first, with the summary and risk indicators, then the cards below it, each carrying details and tagging that deepen the picture.
One piece never shipped: a right-rail chat concept for interrogating individual cards. That thread is exactly where the next version should pick up.
Question — preselected, editable. Change it and the page rebuilds.
Takeaway box — summary + risk indicators, updates first
Adaptive card
Adaptive card
Adaptive card
Adaptive card
Chat rail — concept, didn’t ship.
The report’s anatomy: the question drives the page. Takeaway first, cards adapt below, most relevant first. The chat rail stayed a concept.
AI, with judgment
The hard design work wasn’t layout. It was deciding what the model is allowed to do: what gets generated versus what renders straight from source data, how provenance stays visible, and what the analyst sees when the data is thin.
The analyst’s hour, before and after
Before: an analyst kicks off a report and waits eight to ten minutes, sometimes longer, for twenty sections to generate. Of those twenty, they’ll actually use three to five. The rest they scroll past, or stop to double-check against sources they trust more.
After: they ask the question they came with, and in under a minute they have a targeted summary built around it — enough to drive the first phase of the investigation, with provenance in reach when they need to verify.
Results
2.5x: analysts request the AI-native report two and a half times more than the legacy format, one year post-launch
Generation time: 10+ minutes → under 60 seconds
The 2.5x figure comes from our product support team: current customers are running two and a half times more AI reports than legacy reports. Their reasons are simple — the AI report is more targeted, more informed, and gives them the summarization they need for the initial part of an investigation.
Usage proves adoption. The 10x drop in generation time is the start of the margin story: the legacy format was expensive to produce and hard to sell.
What I’d do differently
The cards already adapt to the entity and the question. What this version doesn’t do is let you go deeper without leaving: expand a single card, interrogate one insight, follow a thread. It summarizes well. The next version should let analysts explore. If I rebuilt it today, I’d design those jumping-off points from day one instead of treating the summary as the destination.
← Previous
Next →