CRUX + ATAK

01Operational question

Special-operations users navigate, communicate, manipulate geospatial information, and make time-sensitive decisions while moving, wearing equipment, working in low light, and managing intermittent connectivity. ATAK, the Android Tactical Assault Kit, supplied the mobile geospatial environment for navigation, position sharing, targeting support, collaboration, and real-time information exchange. CRUX was a programmable, hardened physical controller designed to let an operator invoke a defined, multistep ATAK workflow through a tactile control.

The operational question: which interactions deserve a physical control, and how must the software behave so that the control reduces cognitive and physical interaction without weakening reliable control of the underlying digital workflow? The decisions at stake were product priorities for an early-stage company with limited engineering capacity and the technical narrative for federal opportunities.

02Why the problem was difficult

• Constraint, not preference. Hands occupied, attention on the environment, gloves, low light, equipment load, and degraded communications shaped what an interaction could reasonably demand; an interface that worked at a desk behaved differently in the field.
• Automation requires stability. A programmable button can only replace a multistep digital workflow if that workflow is understood and stable enough to compress; variation breaks it.
• A simple request hides a system. "One button to do this" implies the invoked workflow, the receiving function, application state, required data, event sequence, failure handling, confirmation, offline behavior, and hardware–software synchronization.
• An existing ecosystem. CRUX had to integrate with the operator's mission application and the TAK network rather than create an isolated interaction model.
• Evidence versus preference. Operator feedback had to be treated as evidence about the workflow, with each failure classified by cause, not as a vote on whether a design was liked.
• Capacity. Every field observation competed for scarce engineering effort, so prioritization needed criteria that distinguished platform capability from customer-specific requests.

03My role

As Product Manager for tactical human-machine interaction at Elysian Labs, I owned the path from operator mission to engineering-consumable requirement.

• I conducted mission discovery directly with special-operations users and institutional stakeholders, with SOFWERX providing structured operator access, and my own Special Warfare background supplying the context behind what users described.
• I decomposed workflows, translated operator language into functional requirements, interface behavior, integration assumptions, and acceptance logic, and preserved the operational rationale with every requirement.
• I evaluated prototypes under realistic conditions, classified failures by root cause, and carried the evidence into prioritization, the roadmap, and pre-RFP capture and proposal content.

04Data architecture

Dependency map

For each workflow I mapped where the interaction depended on ATAK, the mobile device, hardware state, required data, network connectivity, and external information-sharing behavior. The integration analysis covered command routing, application state, event sequencing, latency, exception and recovery behavior, degraded-connectivity behavior, and hardware–software synchronization.

physical controlhardened device behaviormobile operating environmentATAK functionnetwork conditionmission workflowoperator confirmation

05Methodology

Mission discovery

Discovery started with the operator's mission, not with a proposed feature: what the operator was trying to accomplish, how the current workflow actually worked, and what environmental conditions constrained it. For each use case: what decision or action completes the task, what information is required first, which steps need visual attention, which need physical interaction, whether hands are occupied, whether the task is performed while moving, how many taps, screens, confirmations, and transitions intervene, what happens when connectivity degrades, and which part of the workflow already belongs to ATAK.

mission objectivecurrent workflowoperating constraintfriction pointrequired capabilityacceptance condition

Workflow decomposition

Each workflow became a sequence of operator and system actions, examined at the level of individual taps, screens, confirmations, transitions, and wait states between intent and response. Candidate workflows for a physical control were assessed on frequency, time sensitivity, repeatability, cognitive cost, physical awkwardness, and standardization.

mission objectiveuser taskrequired informationdevice and application stateaction sequencefriction pointrequired system behavioruser confirmation

Translation into requirements

Each requirement carried what the system should do, under what conditions, how the user should experience it, what constraints matter, and how success is known. Engineers usually have several technically valid implementations; the rationale let them trade off without removing the operational value.

Prioritization

Field observations were weighed on mission importance, recurrence, applicability across workflows and communities, architecture fit, engineering effort, reuse across customers, and relevance to active demonstrations or federal opportunities. That analysis separated three layers.

reusable platform capabilityconfigurable product behaviorcustomer-specific implementation

06Validation

The prototype tested whether the interpretation of the workflow was correct, in the conditions where it would be used.

requirementprototypeoperator interactionobserved behaviorfriction analysisrevised requirementproduct refinement

• Conditions. Movement, gloves, low light, equipment load, time pressure, and intermittent communications.
• Indicators. Interaction steps, attention demand, confirmation clarity, field accessibility, execution reliability, and continuity between operator intent and system response.
• Root-cause classification. Each failure was attributed to requirement interpretation, action sequence, visual-attention demand, physical ergonomics, environmental assumptions, ATAK integration, connectivity behavior, hardware–software synchronization, or effects on adjacent workflow steps.
• Anchor. One question governed evaluation: does the prototype improve the mission behavior identified during discovery?

07Output

• Functional requirements with operating conditions, user experience, constraints, and acceptance conditions attached, each carrying its operational rationale.
• Interface behavior and state definitions: how the user moves between system states and what response each action generates.
• Integration dependency maps across CRUX hardware, the mobile device, ATAK, data, and connectivity.
• Prototype evidence with classified failure causes and revised requirements.
• Roadmap inputs distinguishing platform capability, configurable behavior, and customer implementation.
• Federal proposal inputs: mission analysis, workflow definitions, architecture inputs, implementation assumptions, solution narratives, and technical differentiators.

mission problemuser workflowtechnical requirementproposed capabilityintegration assumptionoperational value

08Result

• Operator requests became engineering-consumable requirements that preserved mission intent through implementation tradeoffs.
• A recurring requirement across special-operations communities was treated as platform capability; mission-specific variation became configuration; specialized needs stayed customer implementations, which protected the core architecture.
• Field evidence, rather than feature requests, drove prioritization and roadmap decisions.
• The same discovery output shaped pre-RFP capture and proposal narratives, connecting operator, Product, Engineering, and federal stakeholder through one traceable sequence.

mission workflowstructured requirementengineering tradeoffprototype observationproduct priorityfederal technical narrative

09Tradeoffs and limitations

• Speed versus flexibility. A physical control compresses one stable workflow; it cannot absorb workflow variation without becoming a menu again.
• Local-first behavior. Degraded connectivity forces confirmation and state handling onto the device, which raises synchronization complexity.
• Access to operators. Evaluation realism depends on structured access to users and on the fidelity of simulated conditions.
• Capacity. Prioritization criteria are a response to scarcity; some valid customer requests remain unbuilt by design.
• Public presentation. Workflows, configurations, and customer specifics are generalized here; the interaction and integration patterns are the transferable content.

10What this demonstrates

• Customer discovery
• Product requirements
• Integration architecture
• Tactical-edge design
• Prototype validation