About Designing the operational cockpit for distributed edge assets Case study 2 Case study 2 Dumps

Kerala

Call me Manu Product Designer · AI Builder

I shipped the feature. Watched them ignore it. Sat with that for a while. That session replay said more than any brief ever did and I knew I had to change how I work. I don't design from assumptions anymore. I design from what I see. My work lives where humans meet AI systems. High stakes. Dense data. No room for noise. Get it right, and someone somewhere makes the right call at the right time. Get it wrong, and nobody tells you they just find another way around it. I know because I've seen both.

7 Years 100+ projects Co Lead 40+ member teams

Home

Designing the operational cockpit for distributed edge assets

Context The design problem What V1 shipped The question we should have asked sooner What the sessions showed The reframe What V2 changed What I'm watching for in phase 2 What this project taught me

Kerala

2026 · Product Designer

Designing the operational cockpit for distributed edge assets

Context Armada builds the platform layer for edge computing compute and connectivity in places traditional cloud can't reach. Oil rigs, satellite terminals, drones, cameras, connectivity hardware in the field. Fleet Map is Atlas's operational cockpit. The surface where an operator lands, sees the health of their distributed fleet, and knows where to focus.

But Fleet Map serves customers whose operational realities have almost nothing in common

Client 1 monitoring connectivity through extreme weather

Client 2 managing satellite service delivery

Client 3 offshore infrastructure operations

The design challenge One interface, built to serve operators whose jobs barely overlap

the platform in action

The Design problem Three overlapping challenges shaped every V1 decision.

Heterogeneous assets Eight asset types, each with different operational data. A Satellite Terminal is defined by its service line address and last known location. A Drone is defined by battery, takeoff time, and operational status. Designing a single asset detail pattern that respects these differences without fragmenting into eight bespoke UIs was the first constraint everything else pushed against.

Starlink Terminal asset card Information are representational

Five status states, all consequential Healthy · Attention · Critical · Offline · Unknown Legible at continental zoom (3-pixel dot) and at street zoom (full card). Legible under clustering, filtering, and overlays.

Real-time by nature Fleet Map isn't a report it's a feed. Live status, alert transitions, event notifications, updating without disorienting the operator.

What V1 shipped Five design bets, each defensible at the time.

Filters as primary navigation Asset type · Status · Groups · Accounts. Land, filter down, act.

One asset detail pattern, adapted per type Same shape, same anchor, same action different metadata per type. Design system stayed honest.

A five-state status system Color + icon + weight, calibrated to survive every zoom.

Hover-for-context, click-for-action Lightweight tooltip on hover. Full panel on click.

Fleet map V1 Information are representational

The question we should have asked sooner After V1 shipped, the next round of features was scoped and ready. Add layers. Extend filters. Improve clustering.

I pushed to ask a different question first: Is Fleet Map actually being used?

We'd shipped V1 and started planning what came next — without checking whether the thing we were building on top of was working.

How we answered it Datadog session replays across several customer accounts. Not surveys. The actual sequence of clicks, hovers, scrolls, and abandonments. Qualitative behavioral analysis. Pattern recognition, not statistical rigor.

SESSION REPLAYs Information are representational

What the sessions showed The pattern was consistent across accounts and consistently not the story V1 was built around.

Users bypassed Fleet Map entirely Operators went straight to Global Search. Typed an asset name. Jumped to the detail page. Fleet Map was often never opened.

When they did open it, they were verifying, not discovering Search first, then map, to confirm location or see what's around it.

Hover interactions weren't informative enough Users hovered, learned very little, moved on.

Small fleets skipped the map entirely Under 5 assets → the listing view won. A map to show 5 points adds nothing a list doesn't.

The detail page was the destination Users landed there, scrolled through live stats, stayed. Fleet Map, if it appeared at all, was a stop along the way.

Fleet Map wasn't broken. It was beautiful and functional and users skipped it. A scenic route past the thing they actually needed.

The reframe The findings pointed at two things at once.

Where is this asset? What's around it? What's the health of the region? What's affecting it? Qualitative behavioral analysis. Pattern recognition, not statistical rigor. Search answers where. Fleet Map answers what's the state of my operation, spatially. Different questions. Different tools. No reason for them to compete.

Fleet Map's role was wrong

V1 assumed Fleet Map is where users find their assets. Reality - Global Search does that faster.

What Fleet Map can uniquely offer Spatial understanding

The customers weren't one audience

Session data made it undeniable Customers weren't using Fleet Map similarly because they weren't running similar operations.

Clients What they actually care about

Client 1 Weather + terrain-driven connectivity

Client 2 Terminal performance, coverage geography

Client 1 Live asset telemetry across sites

V1 treated them as one audience. They were several.

The direction this pointed Fleet Map isn't one tool doing one job. It's a spatial intelligence platform:

Map as the substrate

Layers of operational context on top

Some universal, some customer-shaped in how they're used

Search gets you to an asset. Fleet Map gives you the world around it.

What V2 changed Six design moves. Each traces back to one of the two shifts search complement, or layered polymorphism.

Leading with fleet state, not filters V1 opened with a filter bar. V2 opens with a summary: total assets, critical alerts, warnings. The opening move shifted from narrow this down to here's the shape of your operation.

Weather as a first-class layer Toggleable overlay. Correlates device performance with environmental conditions in real time. Available for customers who need it (Alaska DoT), invisible for those who don't.

Starlink performance heatmap (H3 hexagonal grids) Terminal and service line performance across regions, at any zoom level. Purpose-built for satellite operators.

Progressive disclosure for cluster + asset interactions Consistent interaction model at every zoom level

Live asset count panel Total assets, broken down by status. Updates with filters. Turns Fleet Map into a live health readout, not just a spatial view.

Richer cluster hover popover Categorized information assets grouped by type and status. Selecting from within the hover filters the map. Hover became a working interaction, not just a preview.

What I'm watching for in phase 2 V2 is in development. The impact is ahead. But I know what the signals are.

Does Fleet Map open after search, not before? The reverse of V1's pattern. Session replay will tell us within weeks.

Does layer engagement split by customer type? If polymorphism is real, the split will be clean. If engagement is uniform, the thesis was wrong.

Do sessions get longer and interactions deeper? V1 sessions were shallow. V2 should reward staying in the map

Things I already expect to revisit

Layer toggles won't scale forever As Atlas grows, a flat toggle list will break. Fleet Map will need a structured way to help operators configure their view.

The map as canvas for AI If Fleet Map's job is spatial understanding, the next question is whether it stays passive — or whether AI starts surfacing anomalies, predicting failures, and recommending responses directly on it. The AI work I'm leading in parallel points that way.

What this project taught me

Ship, then look. V2 is better not because we designed it more carefully — because we let real usage tell us what V1 was actually for. Design without observation is guessing.

Beautiful and bypassed is a real failure mode. Fleet Map V1 wasn't broken. It was well-designed and users skipped it. Usability tests don't catch this — they measure whether users can complete tasks in the interface, not whether users open it at all. Adoption is a design problem.

Polymorphism is structural, not decorative. When a product serves customers with distinct operational realities, "one interface for everyone" is either a lie or a lowest common denominator. Layering is one answer. Pretending the customers are one audience is the failure that led to V1's usage gap.