Every anomaly investigation started the same way. Screenshot the chart. Paste to Slack. Lose the thread.
The conversation
belonged inside the chart.
A native annotation and commenting layer for Quantive Signals — an internal feature request from the VP of Product that brought anomaly investigations back into the data where they belonged.
Problem
Analysts left the product to discuss chart anomalies — screenshotting to Slack broke context and buried decisions in threads with no link to the actual data.
What I did
Designed an in-chart annotation layer: threaded comments anchored to data points, with a gesture system that didn't conflict with existing pan/zoom controls.
Outcome
Conversations stayed inside the product. VP-requested feature shipped to the full internal team at Quantive.
01 / Context
Where this came from
Quantive Signals was Quantive's analytics product — a platform for monitoring KPIs, detecting anomalies, and surfacing signals in business data. I was a Product Designer at Quantive when the VP of Product flagged a recurring workflow breakdown they kept seeing in user behaviour data.
The brief was internal and direct: analysts were doing their actual investigation work outside the product. When they spotted something anomalous in a chart, the conversation about it — what caused it, what was ruled out, what the conclusion was — happened in Slack and email. Quantive Signals was the place where the data lived, but not the place where the thinking happened.
My job was to design a way to bring those conversations back into the tool — anchored to the specific data they were about, without getting in the way of the analysis itself.
02 / Problem
The data stayed. The context left.
"Someone spots a spike. They screenshot the chart, paste it into Slack, and a thread starts. By the time six people have replied, nobody remembers the exact date range, what had already been ruled out, or what the conclusion was."
The Slack screenshot workflow had three compounding failure modes. First, context decay — a screenshot of a chart is a frozen moment; anyone joining the thread later couldn't zoom out, change the date range, or see what happened before and after the anomaly. Second, thread fragmentation — the same anomaly would spawn multiple independent Slack threads as different analysts noticed it. Third, no audit trail — once the investigation reached a conclusion, that conclusion lived in a Slack thread that would be impossible to find three months later.
The investigation and the evidence were in different places. That gap was the problem. Decisions were being made disconnected from the data that justified them — and there was no record connecting the two.
03 / The Hard Part
Two drag gestures. One chart.
Adding comments to a product is straightforward. Adding comments to an analytics chart — where the chart already has its own drag interaction for zooming and panning — is an interaction design problem.
The gesture conflict:
Click + drag on a chart = zoom into a date range. This was core to the analytics workflow — analysts used it constantly.
Click + drag on a chart = annotate a date range with a comment. This was the new feature I needed to introduce.
Same gesture. Opposite intended outcomes. The interaction design had to resolve this without removing either behaviour.
I explored several gesture disambiguation strategies: a mode toggle (annotation mode vs. explore mode), a modifier key (hold Alt + drag to annotate), a toolbar switch, and a press-hold before drag. Mode toggles and toolbars added too much intentionality friction — you'd have to actively decide to switch modes before every annotation. Modifier keys worked on desktop but not touch.
The solution was press-hold before drag-to-annotate. A standard drag triggered zoom as before. A brief press-hold (300ms) before dragging entered annotation mode, showing a visual affordance that the chart had shifted state. This matched established gesture patterns from mobile and required no mode switching. Engineering flagged it as the trickiest implementation challenge — and they were right — but it was the correct interaction.
04 / Design Decisions
4 decisions that shaped
the annotation layer.
Every decision had a wrong answer that was easier to implement. These are the right answers and why they mattered.
Range-level anchoring over point-level or event-level
Analysts discuss trends, not coordinates. The annotation should match the actual unit of analysis.
I tested three anchor models: point-level (pin a single datapoint), event-level (pin a tagged event), and range-level (select a date window). Point-level seemed the most precise, but it failed quickly in user testing — analysts almost never care about a single moment, they care about what happened over a period. "Revenue dropped between the 14th and the 22nd" is a range-level insight, not a point. Event-level was too rigid — not every anomaly has a tagged event. Range-level won because it matched the natural language of how analysts actually described what they were investigating.
Two coexisting modes: tap for point, press-hold + drag for range
The gesture design had to solve the zoom conflict without adding a mode toggle or removing existing behaviour.
Rather than choosing between single-point and range annotation, I kept both. Quick tap on a datapoint = add a point comment. Press-hold + drag = select a date range and add a range comment. The press-hold threshold (300ms) was short enough to feel immediate but long enough to clearly distinguish intent from an accidental touch. The visual affordance — a faint highlight appearing during the hold — confirmed the mode shift before the drag began. Engineering confirmed the implementation was complex, but the user experience was seamless on both desktop and touch.
Threaded comments with a "resolved" state — not a flat feed
Anomaly investigations have a lifecycle. The structure should reflect that.
Flat comment threads treat investigation and social conversation as the same thing — a stream of messages. But anomaly investigation has a clear structure: hypothesis → evidence → conclusion. Threading preserved that lifecycle. A top-level comment could represent the hypothesis; replies added evidence and counter-evidence; a "resolved" status closed the thread when a conclusion was reached. The resolved state was the most important detail — it created an audit trail. Six months later, anyone looking at a chart could see what had been investigated, what the conclusion was, and who reached it.
Right-side collapsible panel — never a modal, never full-screen
Commentary on data is only useful when you can still see the data.
Early explorations used a modal for comment creation — you clicked a datapoint, a modal appeared, you typed, you submitted. It tested poorly immediately: analysts couldn't reference the chart while writing because the modal covered it. A bottom drawer was slightly better but compressed the chart uncomfortably. A right-side collapsible panel — the same pattern used in code review tools — solved it cleanly. The chart stayed fully visible at all times. The panel could be collapsed entirely for analysis-only work. The panel width was fixed (not resizable in V1) to keep scope tight.
The hardest interaction design problem wasn't the comment UI. It was making a drag gesture for annotation coexist with an existing drag gesture for zooming.
— On designing the annotation layer for Quantive Signals
05 / The Feature
What shipped —
the annotation layer in detail.
Point-level quick-tap commenting
Tap any datapoint on a KPI chart to anchor a comment to that exact coordinate. The comment pin persists on the chart so anyone viewing it later can see where the annotation is anchored — and what the value was at that point.
Range-level drag-to-annotate
Press-hold then drag across a date range to select a window for a comment. The selected range is highlighted on the chart and persists as a shaded region under the annotation — keeping the visual connection between comment and context intact.
Threaded discussion with resolved state
Every annotation supports a threaded reply chain. A "Resolve" action closes the thread and marks it with a concluded status — creating a permanent audit trail of every investigation that ever happened on that chart.
Searchable, persistent comment layer
All annotations are indexed and searchable by keyword, author, and date range. They persist across sessions, across users, and across time — so the work done in an investigation six months ago is still findable and legible today.
06 / Outcome
Measured at 8 weeks post-launch
35% increase in investigation activity measured by comment thread creation rate per detected anomaly — showing that analysts were engaging with anomalies more systematically, not just faster.
28% reduction in Slack and email usage for data discussions in the first eight weeks. This was the VP of Product's primary metric — the one that motivated the feature request.
Root cause identification time dropped from 4.1 hours to 2.9 hours average. This was the most important metric to the product team — it validated that the annotation layer was functioning as an investigation tool, not just a social layer.
Feature tested clean immediately after implementation. No design revisions requested by engineering or stakeholders post-handoff.
07 / Reflection
What I'd redesign
"The feature solved the right problem. The notification system created a new one."
V1 notifications were event-triggered — every comment in a thread you were part of sent an individual alert. In normal usage, this was fine. But during active anomaly investigations — when a spike in revenue or a dip in conversion had multiple analysts piling in simultaneously — the notification volume became its own problem. People started ignoring the alerts entirely, which undermined the whole point of the threading model.
What I'd do differently: a digest model from day one. A daily summary email: "Here's what changed across the annotations you're following today." Immediate alerts only for direct @mentions or when a thread you're in moves to resolved. This would provide ambient awareness — you're informed without being interrupted. The annotation layer was designed to reduce noise by pulling conversations out of Slack. The notification system, in its first version, brought some of that noise back through a different channel. That's the lesson: ambient information tools need ambient notification models to match.
Want to see the Figma?
7 days of decisions don't
fit on one page.
The full Figma has all anchor states, gesture interaction specs, the notification model, the threading logic, the panel layout, and every edge case that came up in the process. If you want a walkthrough, reach out.