I’ve never understood why we’re still designing for certainty when things are chaotic.

Like networks will stay up (or won’t be down), that roles never swap, and you can SW-define absolutely everything. Psychologists probably have a term for it that I won’t attempt to find!

It’s easy to identify problems, so instead of another day-rate round-table about “challenges”, here are three v. simple design principles that I think work, whether designing for a platoon sergeant or a paramedic.

I’m mainly talking information systems here – comms and sensing. It’s like Antifragile Design (Nassim Taleb) but a different context and unashamedly bottom up.

1. Role-Agnostic Operability

If an Ork Boy can slam the trigger on his shoota, your UI should let the medic direct a sensor without cracking a manual.

If a competent user can’t generate a useful outcome within minutes, the design has failed. Interfaces should hide underlying protocol and RF complexity, enforce safety boundaries by default, and prevent user actions that risk unintentional interference or misconfiguration. Our own Steve Hall has consistently hammered home the need to ‘hide complexity from end users’ and this is merely an extension of the same idea.

As resource constraints grow and capability becomes more distributed, we should assume that roles will blur – a logistics driver might need to deliver an electronic deception effect. The system should support that without specialist input.

There’s precedent for this. Modern defibrillators are a good benchmark: walk-up usability, no configuration, clear feedback. If your system can’t meet that bar, and the answer is “it’s complicated,” it probably isn’t. It’s just tied to a training revenue line and you want someone to de-risk your UX investment.

2. Dynamic Bearer Adaptation

The Omnissiah cares not which bearer you pray to, only that the packet arrives.

In disconnected environments, bearer availability is constantly shifting: terrain, interference, and adversary action all play a role. Systems should continuously monitor available links – mesh, satellite, 4G, even Wi-Fi-6 in a petrol station – and autonomously select the best trust–throughput trade-off.

This shouldn’t require user input. No drop-down menus. No manual toggling. The system should silently fail over and adapt in the background. Anything that depends on operator intervention under pressure is a liability and it’ll either be set wrong or not set at all.

This is hard engineering and underinvested. We’re definitely not there yet.

3. Modular Hardware Integration

You can’t change antenna length with firmware – even the Adeptus Mechanicus haven’t cracked it.

Antennas, RF front-ends, compute modules and power profiles need to be treated as configurable elements, not fixed constraints. If requirements shift – to L-band, higher bandwidth, or different thermal limits – you should be able to swap the relevant components and continue. No programme reset. No requalification cycle.

Hardware won’t move at the pace of software, but it needs to be close enough that it doesn’t hold everything else back. I’m thinking 0.5× the speed of modern SW updates. It must be under 0.1× today.

Writing a requirement for something at the edge?

Firstly, I don’t envy you in this era, but run it through these principles first. If a vendor can’t talk to how they meet these, they’re probably stuck in the lucrative time warp of 2012 tech, but with a good bid team :-).