More Than Panes of Glass

Mar 29

The counter-UAS interface conversation has organized itself around a question of screen count, and screen count isn't what determines whether an operator can work. Density is, and density has to move with the context the operator is standing in.

TL;DR

Screen count is the wrong unit of analysis. Density, information architecture, and interaction design decide whether an operator can work under load.
The operator becoming the fusion engine isn't the failure. Nothing else in the room doing fusion alongside them is the failure.
A permanently dense screen and a permanently simple one produce the same result, which is trust that's come off calibration in one direction or the other.
The Lattice SDK was open fifteen months before the Army deal, so the pane of glass is being filled by an ecosystem with no shared design language. Building one would be an advantage for Anduril, not a cost.
Once these capabilities commoditize, experience is what separates the companies building them.

An operator working C-UAS might be in a command center with five screens in front of them, RF detection on one, radar on another, EO/IR feeds somewhere else. Or on a single Toughbook. Or a tablet in a tent in the woods or walking around at night in the dark. Or an air conditioned trailer in the Nevada desert.

The operators vary as much as the box does. I've talked with warfighters who want one simple screen with only the essentials, and others who want every data point visible all at once. Both are describing something real about how they work, their units run different TTPs, and neither is wrong. The DoD keeps reaching for one-size-fits-all anyway, because historically that read as the cost-effective choice, but for software experiences it never has been. What the variability actually asks for is systems flexible enough to scale and modular enough to meet a unit where it is, which is a harder thing to buy and a much harder thing to write a requirement for.

That variability is the first thing to go when the conversation turns to how many screens an operator should have. In March the Army folded roughly a hundred and twenty existing Anduril orders into a single enterprise agreement with a ceiling of up to twenty billion dollars, and days later issued the first task order under it, eighty-seven million for Lattice as the command and control backbone for counter-drone activities. Anduril's own president spent that week telling reporters there was no money attached to the twenty billion, that it was a contract vehicle and not a check. The number traveled regardless, and Lattice arrived with it, pitching a single pane of glass to replace fragmented toolsets. The interface argument that came along settled into five screens against one, an oversimplification made by people describing an engineering problem in the vocabulary of interface design.

Operator as Fusion Engine

The phrase that stuck came from a C-UAS practitioner writing in Small Wars Journal a few weeks before the announcement, describing an operator working between RF, radar, and EO/IR effectively becoming the fusion engine. The fragmentation is credible and I recognize it. The diagnosis is what I'd push on.

Five screens isn't the problem. The operator being the only thing in the room doing fusion is the problem. Multiple screens can be useful when they give someone enough to feel confident in the command they're about to give. What should sit alongside them is a screen, or part of one, doing sensor fusion, offering a recommendation, working the course of action with them, with the source information underneath staying available when the moment is severe enough to call for it. That might mean many screens and high density and a real amount of load, and I think that's fine when the moment is asking for it.

Density Is a Context Problem

So the variable worth arguing about is density. Rich and dense, or obfuscated behind progressive disclosure with the top layer kept as simple as it can be?

It has to be both, and it has to be the right one for the context. High density is fine when the moment demands it, and what can't happen is for it to be that way all the time. The inverse is just as bad and gets far less attention, because a simplified view that hides the reasoning behind a recommendation leaves an operator unable to understand what the system is doing, which leaves them unable to meaningfully approve it. Either failure pushes trust off calibration. The operator doesn't trust the system and won't use it, or they overtrust it and get accustomed to approving everything.

The tools I've seen are static and dense continuously, sometimes with the most critical thing sitting three clicks down, and that's a very easy solve. The harder problem is what happens when the interaction model becomes chat. Chat can be fast, but I can't monitor it the way I can monitor a dashboard. Bury the reasoning underneath a recommendation on the assumption the system will be trusted, and an operator who doesn't trust it has to go dig, which is friction, and friction under time pressure is where a lot of overload comes from.

Bundling and Unbundling

There's a cycle here I've watched run twice in my career. A landscape gets fragmented enough to be annoying, someone bundles it into one clean package, and what comes out is a monolith trying to be everything for everyone, doing a lot of things poorly rather than a few things well. People get frustrated, a small company unbundles one piece and does that piece extraordinarily well, and eventually the winners grow large enough to start bundling again.

The defense version I've seen is land navigation. The recon Marines I've spent time with, the ones responsible for planning and executing land nav, use a civilian mobile app that costs thirteen dollars, built by one soldier while serving in Afghanistan. It does land navigation and that's about it, but it does that inside a military mental model and vernacular, so it feels familiar to someone trained in combat land nav. Every scout and squad leader I talked to prefers it to ATAK, almost entirely because they don't want the complexity of features they'll never use sitting at the same level as the ones they need. Bundling may be inevitable, and unbundling is every bit as inevitable, which is worth sitting with while everyone is celebrating the consolidation.

Nobody Owns the Pane

Anduril opened the Lattice SDK to third-party developers in December 2024, fifteen months before the Army deal, so the pane of glass everyone is now arguing about is already being filled by an ecosystem. Reduced fragmentation in the data model is a real engineering achievement that solves nothing on its own for the person using the system. An API isn't an operator experience, and the developer documentation is a fair illustration of the distance between the two. Entities, tasks, objects, an API reference, sample apps. Everything a developer needs to publish a track into Lattice, and nothing about what that track should look like when it lands in front of an operator, or how it ought to behave next to the forty other things already on the screen.

In my experience, when SDKs open up, nobody becomes responsible for the experience. I think of the Google Marketplace. Google opened their platform, applications flooded in, the good ones rose and the bad ones fell away, and across all of them the experience was disparate enough that nobody felt much consistency using their own device. But as patterns started to emerge, eventually Google built Material Design which made interaction components common enough that the platform began to feel cohesive.

Design systems have since become an expected part of an open platform, yet there isn't a public one for Lattice. While I understand the security sensitivity, I think that's a huge miss. I'd want it for Anduril because a design language gives every developer on the SDK the means to build toward something coherent for the operators who inherit all of it, and setting that standard strengthens Lattice's position as the SDK everyone prefers for integration. Without it we're in for a few years of disparate products landing in the same pane of glass, each one internally sensible and collectively incoherent — at best — and the operators are the ones who absorb the difference.

Band-Aiding Is Not a Feedback Loop

The strongest counterargument is that companies like Anduril have operator feedback loops no research process could match. They're fielding systems, watching them perform, iterating faster than a study could be scoped.

The access is real and the opportunity inside it is enormous. What's being done with the access is where I push, because it’s unlikely that feedback is being captured, qualified, or synthesized in any meaningful way. Likely, most of it is lost, and what gets retained is anecdotal, at the level of "they said this button should be bigger." I want that too but it isn't deep usability work, and knowing how much opportunity for insight is sitting there unclaimed is the part I find genuinely frustrating. What I hear instead is that companies send field engineers out to work alongside units, and what those engineers produce is bespoke feature sets shaped by that unit's TTPs. That's band-aiding, and it has real value, but what it flags is the fundamentals underneath are immature enough that patching in the field has become cheaper than fixing them.

What I want instead isn't complicated. A designer with research experience going out alongside those field engineers, prototyping in place, capturing what's learned in a form that can travel back and shape sprint priorities instead of dying in a trip report. I've seen how much is available in those rooms in my work, and I've seen how much of it goes by, because the right people aren't there at the right moment to ask, and the people who are there don't always know how to ask without leading the answer.

The design ownership question usually gets asked wrong, too. I've never been in a room on a defense project where a designer was explicitly responsible for the design — before I arrived — and someone is always responsible for it. In defense it's almost never a designer. It's the engineer, making interface decisions out of their own conception of the system they built, so the interface becomes a reflection of the engineering. I was sitting with one recently, someone with a PhD in advanced robotics, talking through a setting that controls how far apart a formation of autonomous ground vehicles should maneuver. She called it inter-vehicle lateral distance. I shook my head, and she grinned, because she already knew why, and asked, “Too technical?” Where we landed was spacing, which is everything someone without a doctorate in robotics needs to know about the distance between those vehicles. That kind of translation is a key value a designer brings to this work, maybe most of it, and it only happens if somebody whose job is to think about the operator is in the room while the thing is still being named.

Capability Becomes Commodity

I don't really think of companies like Anduril or Palantir as startups anymore. The primes were confident these companies would never scale, and now we're watching contract after contract go their way. I should be honest about my limits here, because I've seen a very small sliver of Lattice and I hear mixed things from people I know inside the industry. What I can see from outside is these companies winning contracts repeatedly, and there's a reason for it. I think primes should be really paying attention when they’re being displaced as an incumbent program of record, but from where I sit as a designer I'm incredibly excited about it, less because disruption is interesting and more because of the competitive innovation I hope will reach the warfighter.

These capabilities will become a commodity, and once the capability is common, experience is what separates the companies selling it. We watched that in commercial software in the 2010s. Anduril has the disruption and the brand. Whether they can back it with the experience layer is the open question, and I think it's the one that decides how much of this decade they end up owning. The playbook for how their competitors respond is known, and we've watched it run before. Whether any of the primes or incumbents run it before it's too late is a different question, and I’m excited to see how it plays out.

More Than Panes of Glass

Design in the Loop