Ansh Tandon / Senior Marketing Manager
← All work
Product UX

Redesigning an AI operations console for network engineers

Nirad AI helps engineers run networks across a whole fleet of sites. The first version demoed well. I'm leading the ground-up redesign so it works when something is actually broken.

Nirad AI V2 prototype: Fleet view. Every city on one map, ranked worst first.Nirad AI V2 prototype: Drill into a city. Click the worst city to see its sites and every device.Nirad AI V2 prototype: Open a device. Risk grade, status and an AI prompt that only recommends.Nirad AI V2 prototype: What fails together. Correlate alarms to find failures that share a cause.Nirad AI V2 prototype: Nucleus. Every site around the controller, ringed by state.Nirad AI V2 prototype: Territories. Clients as nodes, worst first, one click to break down.V2 prototype · not the final build

Real V2 prototype screens, captured click by click. Sample data, client names anonymised.

Role
UX lead, working with the platform's engineer
When
August 2026 to present
Output
High-fidelity prototypes, light and dark
Users
Network engineers at customer organisations
~20screens in scope, redesigned rather than reskinned
4reference products studied for specific patterns
1question every screen answers: what needs me right now?

Why this project is a stretch

My UX background is websites and marketing funnels. An operations console is a different discipline: dense, stateful, used under pressure, by experts who will notice every wasted pixel. I took it on knowing that, and set the project up to compensate. Before any design work I ran customer interviews to hear how engineers actually use the console day to day, then combined what they told me with the full product context and the constraints into a working brief and a phased plan.

What was wrong with V1

I audited the first version screen by screen. Four problems stood out:

  • A decorative topology. The network was drawn as concentric rings. It looked good with a handful of sites and stopped being readable as the fleet grew.
  • Colour as mood, not state. Colour was used to make screens feel alive rather than to tell an engineer what was healthy, degraded or down.
  • Weak contrast in places where the information mattered most.
  • Inconsistent density. Some screens were sparse, others crowded, with no system behind either.

Each finding became a design principle, so the audit doesn't just describe the old product. It constrains the new one.

V1 What I found

Concentric-ring topologyBreaks as fleet grows
Colour used for moodSays nothing about state
Low contrast on key dataHard to scan
Density varies by screenNo system

Principle What replaces it

Fleet list first, topology on demand
Colour means state, nothing else
Contrast budget for critical values
One density scale across screens

Each audit finding became a rule the new screens have to follow.

Who it's for

The users are network engineers at customer organisations, not the partners who sell the product. I set triage as the primary mode: the engineer opens the console because something needs attention and wants to find it fast. Ambient wall-screen monitoring is secondary.

That's a working assumption, not a finding, and I've recorded it as one. It still needs confirming with a real engineer before the rest of the screens are built on it.

What I'm borrowing, and from where

ProductWhat I'm taking from it
DatadogInformation density and disciplined use of colour
GrafanaA customisable panel model
Cisco MerakiFleet lists and device-detail patterns
Juniper MistHow an AI verdict is presented to an engineer

One rule runs through all of it: the AI recommends and the engineer decides. The interface never presents an AI action as already taken.

How the work is sequenced

  1. Design language first. Type, colour for state, density and components, in light and dark mode.
  2. The AI Dashboard as the proving ground. It's the screen the CEO demos, so it's the first real test of the system.
  3. The remaining screens, built on the proven system.

Desktop is the priority, with mobile as a secondary target that doesn't block anything. The prototypes are handed to engineering to build in production.

Phase 1 · DoneDesign languageType, state colours, density, light and dark
Phase 2 · NowAI DashboardThe first screen built on the system
Phase 3 · NextRemaining screensRolled out on the proven system

Where the redesign stands.

Where it stands

What you see at the top of this page is V2: a working prototype of the Network screens, running on sample data. It is not the final build. The design language is set, the fleet, city, device, correlation, Nucleus and Territories views are clickable, and the prototype is handed to engineering to build in production. The final build will change as engineering connects real event data.