Designing for depth: how we redesigned PeakMetrics' narrative dashboard

When PeakMetrics' analysts wanted to see how a story branched across coverage, they were exporting their data into spreadsheets and color-coding rows by hand. The dashboard had everything else they needed, millions of mentions across news, social media, and broadcast, except a way to represent the structure that mattered to them.

This is a real pattern in narrative intelligence design, and in any analytics product where the data underneath has structure the dashboard is not showing. A flat list, even a sophisticated one, hits a ceiling the moment a story stops being a single thread and becomes a tree.

This piece is the design deep-dive. For the project overview, see our PeakMetrics case study.

The problem with flat mention dashboards

PeakMetrics tracks how narratives develop across millions of mentions, the raw posts, articles, and broadcasts pulled from news, social media, and broadcast sources. The platform already had a Narratives feature: a way to cluster those individual mentions into the bigger story they collectively tell. Users could filter by narrative, set up alerts, monitor sentiment.

The problem was not the concept. It was the depth, and the connection between narratives. A flat list could tell you a narrative existed, it could not tell you that a smaller story was actually a branch of a bigger one, or that two seemingly separate narratives shared the same root.

A narrative like "a major manufacturer's safety crisis" actually contained multiple distinct threads: a product defect, internal whistleblower testimony, a regulatory investigation. Each thread had its own coverage volume, sentiment trajectory, and risk profile. But the existing dashboard treated "a major manufacturer's safety crisis" as one flat container. Analysts knew the structure was there, the tool did not show it.

So they did the work themselves. Export to spreadsheet. Color-code rows. Manually tag sub-topics. Maintain a parallel system in their heads to keep the structure intact.

This is the silent friction that breaks complex data visualization UX at the high end of the market. Power users adopt workarounds, and the workarounds become the actual workflow. The dashboard becomes a data source, not a thinking tool.

What PeakMetrics needed, narrative layers you can zoom into

After redesigning PeakMetrics' Notifications experience, we were asked to extend the Narratives surface with a new concept we called Layers. The goal was to give the existing flat narrative system depth, without breaking the workflows analysts already relied on.

Two design constraints shaped every decision.

First, the flat view had to remain the default. Analysts who came in for a quick daily check should not have to opt out of complexity. They should not have to learn a new UI to do what they were already doing.

Second, the layered view had to be more than a fancier list. If users had to mentally map between "the list I am used to" and "this new thing," the workaround would just shift from spreadsheets to mental gymnastics. The new view needed to make the structure obvious in a way the list could not.

That meant a different visual representation entirely.

Designing the zoom, progressive disclosure for narrative data

The Layers view is a bubble map. Each narrative becomes a circle, sub-narratives nest inside as smaller circles. A sub-narrative is not a smaller version of the parent, it is a more specific story that emerged from the same underlying coverage. "A major manufacturer's safety crisis" branches into "supplier delays" branches into "regulatory inquiry." The bubble map renders that branching as nesting. Size encodes mention volume, nesting depth encodes specificity. The visual immediately communicates what a flat list cannot: that some stories contain worlds within them.

But the bubble map alone does not get a user anywhere useful. Someone looking at a complex narrative needs to navigate, not just see. So we added an abstraction slider at the base of the map. Move it left, sub-narratives collapse into their parent clusters. Move it right, the full hierarchy expands. Transitions are smooth, not stepped. Users move fluidly across levels of detail without losing their sense of where they are.

This is progressive disclosure applied to narrative data. The user controls the resolution. They see the whole landscape when they are orienting, and they zoom into specifics when something demands attention. The dashboard does not decide for them.

Two views, one truth, respecting different mental models

The bubble map worked beautifully in testing for about half the people we spoke to. The other half kept trying to find a list.

Not because the map was hard to use. Their mental model for working through data was sequential, not spatial. They wanted to scan, skim, click through, the way you work a table or an inbox. A bubble map asks you to visually orient first, some users never got comfortable with that step.

This is a real product decision moment. Build the map better, or accept that not every user thinks spatially?

We added a synchronized list panel to the right of the bubble map. Both panels represent the same narrative hierarchy. The list is a linear rendering of the same tree structure the map shows spatially.

The synchronization was the critical part. Click a bubble in the map, the corresponding list item highlights. Click a list item, the bubble highlights. Selection state updates in real time, bidirectionally.

This was not redundancy. It was calibration. Especially for the bubble map, which was new to users, having a familiar list right next to it built trust in what they were seeing. "Yes, that big bubble is the same crisis narrative at the top of my list, and the threat score matches in both places." Two surfaces confirming each other.

The trade-off was real. The split panel costs screen real estate. Map gets about 60% of the horizontal space, list gets about 40%. On smaller screens we collapsed to tabs rather than try to fit both. Loss of simultaneous visibility was a cost, but cramming both into a constrained layout would have created worse problems than it solved.

Filters as navigation, not refinement

The other surface that mattered more than we initially thought: the filter panel.

Most filter UIs are designed for exploratory mode. You have a broad result set, you narrow it down. Filters are secondary, something you reach for after you have a starting point.

PeakMetrics users came in the opposite way. They opened the app knowing exactly what they were looking for: mentions of a specific narrative, from a specific channel, in the last 48 hours. Their workflow was closer to targeted search than browsing. The filter panel was their entry point, not their fallback.

The existing design treated it like a buried utility. Filters were hidden, options were not pre-counted, no clear signal that any particular selection would return useful results. Users had to commit to a filter before they had any confidence in what the app would show them. Predictable result: they applied a filter, got an empty or overwhelming result set, undid it, tried again.

We redesigned the filter panel as a primary navigation surface. Six filter dimensions exposed simultaneously: Date Range, Channel, Domain, Narrative, Author, Language. The key addition was mention counts alongside every filter option, visible before you apply.

You can see "Twitter" has 748 mentions and "Blog discussions" has 23 before you decide whether to select either. This single change removed the most common complaint in user testing: "I applied a filter and got nothing or everything."

A "Show results" button previews the result count before applying. Reset is always visible. No dead ends.

Filters and notifications are usually treated as utility features that come after the "real" product is figured out. On a platform where users come back daily to track evolving situations, they are two of the most important surfaces in the product.

Designing trust into AI

The AI-generated summary was the most iterated element in the detail view. Early versions read like data reports, dense, descriptive, full of percentages, no point of view. Analysts could read one and still not know what the narrative actually was, or whether it warranted action. The signal was buried under summary statistics.

We rewrote the brief. The summary now leads with risk level, not volume. It names the specific channels driving the narrative, the outlets and accounts where the story is concentrated. It surfaces the key messages being propagated, the actual claims circulating, not just the topics. The structure mirrors how a communications director would brief a leadership team: what is the story, where is it, what is being said, how bad is it.

Getting an AI summary to produce that kind of output took more prompt iteration than any other AI feature in the product. Volume metrics are easy to summarize, framings are not.

The summary is one of two AI surfaces in the detail view. The other is the Threat Score.

The Threat Score is a 0 to 10 AI-generated reputational risk signal. It appears across the workspace overview, the narrative list, and the detail view. Teams use this score to decide which narratives deserve a response. A misread has real consequences.

The first version was just the number. A 7. Color-coded yellow.

In testing, no one trusted it. Not because they thought it was wrong, but because they had no way to evaluate whether it was right. "Where does this come from? When was it calculated? What is it weighing?" Users asked these questions before they would act on the score.

So we made two decisions.

First, make the score legible, not just a number. The redesigned module includes a color-gradient bar (green to red) for instant visual calibration, and a timestamp showing when the score was last calculated. The timestamp addresses the "is this stale?" concern that comes up the moment a number is on screen.

Second, treat the score as a starting point for investigation, not a verdict. The Contributing Factors panel (expandable) lists what went into the calculation: volume velocity, sentiment distribution, channel reach, prominent authors. Most users will never expand it. But for the users who need to defend a decision based on the score, the reasoning is right there.

The Threat Score sits alongside the AI summary and the mentions list, one signal among several, not a standalone authority. That positioning matters. AI in high-stakes contexts has to be a teammate, not an oracle.

Where it broke, and what we changed

Some of the friction was visible in testing. Some only surfaced in production.

What this taught us

Three patterns from this work that hold beyond PeakMetrics.