Skip to content
Back
Case Study · 06 2022–2023

Space Cop: A Space Situational-Awareness Dashboard

A command dashboard for orbit analysts tracking launches, re-entries, breakups, and on-orbit objects. Designed at Tanzu Labs (formerly Pivotal Labs) with weekly user research.

Role Product Designer Themes UI Design Data Visualization Interaction Design

What problem existed?

Space-operations analysts track everything happening in orbit: rocket launches, re-entries, on-orbit breakups, and the thousands of objects already circling. That activity lived across separate tools and feeds, so forming a current picture meant stitching sources together by hand, and the highest-risk events did not stand out from routine traffic. Space Cop set out to put it all in one operational view.

Why did it matter?

Analysts act on a clock, often deciding within minutes whether an object or event needs to be escalated. When the picture is scattered, every decision starts with assembly instead of judgment. One view that leads with risk gives that time back and lowers the chance that a serious event is lost in the noise.

What constraints existed?

  • The data was dense and heterogeneous: launches, re-entries, breakups, and catalog objects, each with its own fields and update cadence.
  • It had to read fast on a large operations display and still work on a phone for analysts away from their desk.
  • Status and risk had to be legible at a glance, in a dark environment, without leaning on color alone.

What role did I play?

This was a Tanzu Labs (formerly Pivotal Labs) engagement, and I owned the product design. We worked as a balanced team and practiced the lean methods Pivotal is known for, including continuous user research instead of a single study up front. Part of the work was teaching the client how to run those feedback loops themselves, so the practice would hold after we left.

What options were explored?

  • A single operations dashboard that summarizes launches, re-entries, breakups, and year-to-date stats, with a command bulletin for context.
  • A tracking map for on-orbit and geostationary objects, where selecting one opens a detail card carrying its risk and key parameters.
  • A focused detail view for a single launch or object, keeping the same risk-first header on both desktop and mobile.
The GEO tracking view: an equatorial belt of objects, where selecting one opens a risk-first detail card for triage.

What tradeoffs were considered?

The main tradeoff was density versus calm. An operations audience wants a lot on screen at once, but a wall of evenly weighted data hides the item that matters. I kept the dashboard dense but ranked, leading each module with its most decision-relevant entry and pushing the rest behind a “view more.” Risk gets a consistent, reserved treatment so it reads first wherever it appears.

How did UX, engineering feasibility, and business strategy intersect?

Working in a balanced team kept the three in the same conversation. Engineering feasibility was a discussion as I designed rather than a later gate, and the weekly user sessions kept the product pointed at what analysts actually needed to decide, not at every field the data could show. The detail-card pattern reused across the map, the launch view, and mobile kept the build economical.

The risk-first header pattern carried onto a phone, so the launch detail reads the same away from the operations floor.

How was the design researched and validated?

We ran user interviews every week, for the length of the engagement. Rather than validating once at the end, each round put the current design in front of analysts, surfaced what did not fit their workflow, and fed straight into the next iteration. That cadence is what made the work effective: the risk-first layout, the detail-card pattern, and the dashboard’s ranking all came from repeated sessions, not a single test. Because we taught the client to run the loop, the weekly feedback habit stayed in place after the engagement ended.

What was learned?

Analysts work in fast decision loops: observe, orient, decide, act. That is the OODA loop, formalized by a U.S. Air Force colonel and still taught in military decision training, and it lines up almost exactly with how product designers implement user feedback loops. The users already thought like designers, which made designing for them unusually direct.

This is still my favorite project I have worked on.

What was the outcome?

  • One operational view that brings launches, re-entries, breakups, and stats together, with risk surfaced first.
  • A tracking map with a consistent detail-card pattern for selecting and triaging objects.
  • A responsive detail view that holds up from a large operations display down to a phone.
  • A research habit the client kept, having learned to run the weekly feedback loop on their own.

This case study generalizes proprietary work into a portfolio-safe narrative. No source code, customer data, internal screenshots, or non-public metrics appear. The focus is on design thinking, decisions, tradeoffs, and outcomes, not on reproducing what employers own.

Resume