Making millions of network events explain a single outage.
Engineers investigating live outages couldn't tell what data was loaded, what was missing, or how evidence across five systems connected together.
- Outcome
- Outage to correlation time reduced from 1 min to under 10 seconds
- Users
- NOC engineers, network engineers, incident managers, IP leadership
Context
When a telecom outage occurs, engineers need to understand what's happening before the impact spreads further. Falcon is the platform they use to investigate incidents, trace affected infrastructure, and determine the fastest path to resolution. It brings together signals from multiple network systems, devices, and monitoring tools into a single workspace.
The challenge wasn't collecting information. Falcon already had access to vast amounts of operational data. The challenge was helping engineers trust what they were seeing, connect evidence across multiple sources, and make decisions confidently while an incident was still unfolding.
This project focused on reducing the gap between information being available and information being understandable.
The Problem
Falcon processed vast amounts of operational data, but engineers still spent the first minutes of every incident determining whether they could trust what they were seeing. Information arrived from multiple systems at different speeds, relationships between sources were hidden behind separate views, and AI-generated answers required independent verification. The cost wasn't just slower investigations—it was a gradual loss of trust in the tool itself.
Over time, engineers adapted by building workarounds. They kept raw logs open in separate tabs, manually stitched evidence together, and treated Falcon as a starting point rather than a source of truth.
The product had become an unreliable source of truth, so users created their own.
Understanding the System
To understand why engineers had stopped trusting Falcon, I approached the problem from three angles: observing live incidents, interviewing users, and analyzing operational data. Each revealed a different part of the story.
Contextual Shadowing
Live incidents revealed a gap between what engineers said and what they did. Engineers routinely waited for data, cross-checked results against raw logs, and relied on workarounds that had become part of their normal workflow.
User Interviews
Interviews across roles showed that trust meant different things to different users, but everyone depended on the same underlying information to make decisions
Operational Analysis
Usage data confirmed the pattern: engineers spent nearly ten minutes gathering context before diagnosis could begin, while critical information remained fragmented across multiple sources.
Key Findings
Research surfaced 18 issues, but most were symptoms of a smaller set of underlying problems. Three root causes consistently appeared across observations, interviews, and operational data.
Trust in System State
Engineers couldn't reliably tell whether data was complete, still loading, or outdated. As a result, they spent time verifying information before acting on it.
Cost of Correlation
Critical evidence was distributed across tickets, logs, topology, and configuration data. Falcon stored the information, but engineers were responsible for connecting it into a coherent explanation.
Lack of Explainable Evidence
The AI assistant operated separately from the evidence engineers were already reviewing. Answers required additional verification, creating friction and reducing trust.
Together, these findings revealed that Falcon's challenge wasn't intelligence. It was helping engineers trust, connect, and act on information during live incidents.
Design Principles
The research surfaced 18 issues, but the solutions were guided by four principles. Every design decision was evaluated against these rules.
Show Information As Soon As It Exists
Engineers should never wait for data the system has already retrieved. Information should appear progressively as it becomes available.
Never Let Incomplete Look Complete
Loading, loaded, and stale states must be visually distinct so engineers can immediately understand the reliability of what they're seeing.
Organize Around Investigations, Not Data Sources
Engineers think in terms of tickets, devices, and incidents—not logs, topology, or monitoring systems. The interface should reflect that mental model.
Trust Requires Evidence
AI-generated answers should always provide a clear path back to the underlying evidence. Confidence alone is not enough.
Reframing the Information Architecture
From Source Based Navigation to Investigation Based Navigation
Falcon was originally organized around where data came from: tickets, logs, topology, and configuration changes. While this mirrored the underlying systems, it didn't reflect how engineers actually investigated incidents. Engineers don't start with a source they start with a question.
A typical investigation required moving across multiple tabs and manually stitching information together. The platform stored the evidence, but the burden of correlation remained with the engineer.
The Shift
Instead of organizing Falcon around data sources, I reorganized it around the unit of investigation: a ticket, device, or IP address. Searching a single identifier now pulls together all related evidence across systems into one continuous workflow.
This reduced the need to navigate between sources and moved the responsibility for correlation from the engineer to the system.
A Key Decision
An early concept explored separate experiences for different user roles. However, incidents frequently move across analysts, engineers, and managers. Role-based views fragmented the investigation and removed critical context during escalations.
Instead, I designed a single shared surface with layered information density—allowing different roles to access the same incident while engaging at different levels of depth.
Outcome
The redesign transformed Falcon from a collection of disconnected sources into a unified investigation workflow, creating the foundation for every subsequent design decision.
Design Decision 01
Making System State Visible
One of the most expensive moments in an outage investigation wasn't diagnosis, it was uncertainty. Engineers often couldn't tell whether they were looking at complete information, partially loaded results, or outdated data. As a result, they routinely waited for all sources to load or manually verified information before acting.
The underlying issue was that Falcon treated data as a finished object. In reality, information arrived from multiple systems at different speeds, but the interface gave little indication of that state.
The Decision
Instead of waiting for all sources to return before displaying results, Falcon now reveals information progressively as it becomes available. Every section clearly communicates whether its data is loading, loaded, or stale.
This shifted the interface from hiding uncertainty to communicating it.
Design Decision 02
Reducing Correlation Cost
Even when Falcon contained the right information, engineers still had to assemble the story themselves. Investigating a single incident often meant moving between tickets, logs, topology maps, configuration changes, and AI outputs to understand how seemingly disconnected signals were related.
The platform stored the evidence, but the burden of correlation remained with the user.
The Decision
Instead of organizing information by source, Falcon now organizes information around the investigation itself. A ticket, device, or IP address becomes the starting point, automatically pulling together relevant evidence from multiple systems into a single workspace.
The responsibility for connecting information shifted from the engineer to the system.
Design Decision 03
Reducing Triage Effort
As Falcon became faster and easier to navigate, a new problem emerged.
On high-volume days, engineers weren't struggling to find information, they were struggling to decide where to start. Hundreds of open tickets could appear simultaneously, each competing for attention with little indication of which incident mattered most.
A faster dashboard still presented a wall of equally urgent problems.
The Decision
Instead of asking engineers to manually triage every ticket, Falcon now performs an initial prioritization pass and surfaces a single Recommended Investigation.
Every open ticket is scored against a transparent set of operational signals:
- Priority level
- SLA proximity
- Shared upstream infrastructure
- Multi-circle impact
- Configuration changes
- Customer impact
The highest-scoring incident is surfaced alongside the specific reasons it earned that recommendation.
Measuring Success
The redesign was ultimately evaluated on a simple question:
Could engineers reach confident decisions faster during live incidents?
Following deployment, incident resolution time decreased by 25%, reducing the time required to move from investigation to action. Engineers spent less time gathering context, manually correlating information, and determining where to focus their attention.
The impact extended beyond speed. By making system state visible, consolidating evidence into a single workflow, and surfacing explainable recommendations, Falcon became a more trusted source of operational truth during outages.
Outcomes
- 25% reduction in incident resolution time
- Faster context gathering during investigations
- Reduced manual correlation across systems
- Clearer prioritization of active incidents
- Increased confidence in recommendations through visible reasoning
Reflection
Designing Falcon changed how I think about enterprise products.
The biggest challenges weren't visual or technical. They were about trust. Engineers already had access to the information they needed; the real challenge was helping them understand whether that information was complete, connected, and reliable enough to act on.
This project reinforced an important lesson: in operational systems, speed alone doesn't create confidence. Trust emerges when systems clearly communicate what they know, what they don't know, and why a recommendation was made.
By shifting Falcon from a collection of monitoring tools to a unified investigation platform, the redesign reduced friction in the workflow while keeping engineers in control of the decision-making process.