Enterprise SaaSNetwork AutomationIntent-Based2019-2025

Apstra IBA

Turning Raw Telemetry Into Answers

Designing a system that lets network engineers define exactly what to watch — and get answers, not just data.

Role

Principal Product Designer (sole designer)

Feature

IBA probe creation, predefined probe library, anomaly dashboards, telemetry pipelines

Client

Apstra → Juniper Networks → HPE

70% faster

MTTR

3x

Probe adoption

Reduced

Misconfig tickets

The Problem

Data without answers

Traditional network monitoring tools flood operators with raw data — counters, logs, traps — and expect them to figure out what matters. The result is alert fatigue, missed signals buried in noise, and slow incident response.

The probe builder was functional but opaque. Building a custom probe required understanding the underlying graph query model. New users consistently struggled to understand what IBA was for before they could learn how to use it.

Design Approach

Two entry points, one system

I restructured IBA around two clearly differentiated user paths. Predefined probes: a library of ready-to-use analytics covering common monitoring needs, with one-click instantiation. Custom probes: a structured visual builder for advanced users, exposing the graph stage model without raw query syntax.

I made the probe pipeline visible — each probe showed its stages as a linear flow, giving engineers a mental model of how data moved through the system. This dramatically reduced the 'why is this probe firing unexpectedly' class of support requests.

  • Probe library with search, category filters, and 'popular' surfacing
  • Visual stage editor with drag-and-connect interface
  • Anomaly timeline showing history, not just current state
  • Threshold editor with preview of historical data

Anomaly Hierarchy

Not all alerts are equal

When probes fired, the original UI showed everything at the same severity. I introduced a three-tier model: built-in detections (always-on, fundamental issues), probe anomalies (user-configured threshold violations), and informational events (state changes worth logging but not actioning).

All IBA output was anchored to the Blueprint — anomalies always showed where in the topology they occurred, with one click to navigate to that element in the graph.

Outcomes

From firehose to filter

IBA adoption increased significantly after the redesign. Support tickets related to probe misconfiguration reduced as the pipeline visualization made issues visible.

The contextual anomaly-to-topology linking directly contributed to the 70% faster MTTR outcome — engineers could navigate from alert to affected infrastructure in seconds.

Reflection

IBA was the feature where I learned the most about designing for dual audiences. The predefined probe library and the custom probe builder were almost two different products — but they had to feel like one. When the vocabulary is consistent, the jump from 'use the template' to 'build your own' feels like a graduation, not a product switch.

Want results like these?

Complex product. Expert users. Real outcomes.

Start a Project