Mercury

Improving operational readiness in Army logistics planning

Overview

Army logisticians relied on a legacy tool (OPLOG Planner) to plan and track personnel and supply readiness. The system was difficult to use, slow to update, and provided poor visibility across units—making it harder for Brigade-level leaders to assess operational readiness.

As a Product Designer and Consultant at VMware Tanzu Labs, I worked on Mercury, a logistics planning application developed with the U.S. Army Software Factory.

By making intentional tradeoffs between flexibility, speed, and security, we designed a system that simplified logistics workflows and improved situational awareness for Army logisticians.

Primary outcomes:

  • Faster logistics plan creation

  • Improved data clarity and confidence for Brigade SPOs

  • Recognized with a Certificate of Appreciation from the U.S. Army Software Factory

Business & Mission Context

The legacy OPLOG Planner supported mission logistics planning but suffered from:

  • Manual, error-prone data entry

  • Inconsistent data visibility across units

  • Limited collaboration and sharing

  • Poor usability for high-pressure operational contexts

This created three critical risks:

  1. Delayed or inaccurate readiness decisions

  2. Low trust in system data

  3. Inefficient coordination between units

The mission was not just to redesign a UI, but to improve how logisticians assessed and communicated readiness under operational constraints.

Strategic Tradeoffs

Several core tradeoffs shaped Mercury’s design:


Tradeoff 1: Data completeness vs. speed of use

Logistics planning involves dense data sets, but requiring full detail upfront slowed planners down.

Decision:
We prioritized rapid plan creation with progressive detail over forcing full data entry at the start.

Outcome:
Planners could build and update plans faster while still supporting deeper accuracy when needed.


Tradeoff 2: Custom dashboards vs. standardized views

Different units wanted tailored dashboards, but customization risked fragmenting shared understanding.

Decision:
We designed a modular but standardized dashboard focused on Classes of Supply, readiness, and open tasks.

Outcome:
Users gained flexibility without losing a common operational picture.


Tradeoff 3: Real-time collaboration vs. security constraints

Modern collaboration patterns conflicted with military security requirements.

Decision:
We supported controlled in-app sharing rather than open real-time editing.

Outcome:
Coordination improved without violating compliance or access controls.

Research and Risk Reduction

Research was used to reduce decision risk, not to chase feature breadth.

We conducted:

  • On-base interviews with logisticians and Brigade SPOs

  • Contextual inquiry into live planning workflows

  • Mapping of information handoffs between units


Key insight:

Users valued clarity and shared understanding more than visual sophistication.

This reframed the problem from:
“build a better planner” → “support faster readiness decisions.”

The outcome of this reframing was a focus on dashboards, plan clarity, and sharing.

Design Strategy

We focused design effort on three high-impact features:

  • Plan creation

  • Readiness review

  • Information sharing

Key decisions included:

  • Linear plan-building workflows over complex branching

  • Hierarchical information layouts for quick scanning

  • Prominent indicators for supply class status and unit readiness

Each interaction was evaluated by its outcome:
Could leaders quickly assess whether a unit was ready for their training or deployment?

Leadership & Collaboration

I worked closely with:

  • Army Software Factory leadership

  • Product managers

  • Engineers

  • Active-duty Army logisticians

My role included:

  • Translating operational needs into product strategy

  • Facilitating soldier design reviews

  • Aligning design decisions with technical and security constraints

  • Supporting junior designers contributing UI components

Outcome:
Design became a trusted input into mission planning discussions, not just interface delivery.

Ownership of Outcomes

My work extended beyond design handoff and I:

Plan creation

  • Helped define success criteria (task time, clarity, adoption)

  • Reviewed feedback from Brigade SPOs post-launch

  • Iterated on dashboard structure and sharing workflows

  • Supported prioritization for the next phase of development

The product was evaluated based on operational outcomes, not just feature completeness.

Reflection

This project reinforced that effective design in military systems depends on intentional tradeoffs.

Key lessons:

  • Speed and clarity often matter more than flexibility

  • Shared understanding is more valuable than individual customization

  • UX can directly influence operational efficiency

If I were to repeat this project:

  • I would instrument readiness assessment earlier

  • I would validate dashboard tradeoffs more aggressively

  • I would push for tighter integration with downstream systems

Mercury demonstrated that even in highly constrained environments, thoughtful UX decisions can improve how critical operational choices are made.