Leading Visual Design to Take a Satellite Telemetry Dashboard From Concept to Amazon Handoff

UMD's App Dev Club paired 16 students with Amazon Kuiper for a semester, and our team was brought in to design and prototype a solution.

Yash, a satellite operations engineer on Kuiper's team, worked directly with that telemetry day to day, so everything we knew about the real workflow, its pressure points, and what "useful" would look like came from him.

The vast majority of my team was ML engineers, backend developers, product leads. My focus was data visualization for anomaly detection. I worked directly with engineering to figure out how to put ML outputs on screen in a way analysts could actually read, and I built every pitch deck and presentation the team used.

Before we touched a single frame

The team sent a reading list before our first meeting, none of which I'd encountered before, so I spent a week with all of it before anything got sketched.

Article

Orbital Mechanics — Classical Orbital Elements

orbital-mechanics.space ↗

Video

Hidden Markov Model

youtube.com ↗

Video

Dynamic Time Warping

youtube.com ↗

Paper

Royal Society Publishing — Orbital Debris

royalsocietypublishing.org ↗

At Amazon, the monitoring team's job is to track things like satellites drifting off expected paths, satellites moving between parking and operational orbit, and potential collision risks across the constellation.  This is a lot of data to manage at once.

Catching any of those meant engineers had to compare orbital elements one by one: load the data, pull up the graphs, look for anything that doesn't fit, and investigate. All by hand.

The whole process had the same issue at every stage: too many manual steps between the data and a decision.

The goal was to surface anomalies automatically so analysts could spend their time understanding and responding to problems, not hunting for them.

When we asked engineers to walk us through their process (load telemetry, compare graphs, look for patterns, investigate), we found most of the time was spent finding anomalies, not understanding them. The interface needed to flip that.

What used to take a full manual scan is now a confidence check. The MVP collapsed the first three steps of the original five-step flow into one.

As we continued to talk to Yash and learn more about his process, four things kept coming up.

For reference, I looked at high-density dashboards in finance and analytics, as well as existing satellite platforms, including SpaceX's Starlink dashboards and traditional orbital monitoring tools.

Existing Starlink Dashboards

What worked

• +High-density data for expert users
• +Seamless data export integrations

What was missing

• —Cluttered layouts that buried critical signals
• —No at-a-glance status.
• —Limited interactivity; charts you couldn't manipulate
• —Designed for experts; excluded non-technical users

Before any wireframes, we needed a visual foundation. We pulled Amazon's Alexa style guide and while engineers were working on identifying a clear backend process, I built a mock login page to feel out whether that language actually fit what we were making. 

From these three goals, two concepts emerged: a General Dashboard as the primary entry point (satellite health, performance metrics, system alerts) and an Anomaly Dashboard as the focused tool for detecting, diagnosing, and addressing specific issues within specific sattelites.

My co-designer and I spent a lot of time thinking about the clarity of our visualizations. I found the most useful question wasn't "does this look right," rather "would someone trust this at a quick glance when something's wrong."

In the lo-fi, that meant moving information into clean quadrants with large headers for easy glancing, then modularizing the more intricate components underneath so engineers could shape those to whatever they judged most useful.

Referenced dashboard models

Revised designs (left) alongside mid-fidelity explorations (right).

We ran three feedback sessions with Yash where we found out which visualizations were confusing, and how close we actually were to the real analyst workflow. 

Three main things came back from those sessions.

I designed the pitch deck from scratch to bring Yash through the early designs. I wasn't just showing work, I was building the package Yash would use to react to it, and that would represent our professional capability as a student group.

Pitch deck designed from scratch.

It was useful, and it was also hard to hear: what we'd built was too tied to Amazon's visual system, and more complex than our engineers could actually ship in the time we had; so we rebuilt the information architecture from the ground up.

Revised low fidelity dashboards.

The dashboard was rebuilt around one continuous workflow: open the tool, find the issue, investigate it, file a report. Every stage maps to a specific pain point from the old manual process.  Since we knew this product would end up being built on by engineers after us, we wanted to make sure we had developed a solid foundation with clear logic.

We settled on a scheme much darker, but with intentional color, since the data is already dense; every decision traces back to one constraint: the interface can't add to the noise.

The version we landed on opens on three plain numbers, running, flagged, under review, so the most important question gets answered the moment you open it.

Anomaly Drill-Down

General Dashboard — Summary Metrics

An earlier iteration used horizontal progress bars to represent each orbital element's value; length is faster to parse than digits across hundreds of rows, but those bars were also harder components to implement. The view we landed on instead reads the values of all of the original bars translated into a single plotted view: more easily scannable and more buildable, with constraints we were working in.

Parking Dashboard — Satellite List

General Dashboard — Scatter Plot

The interface runs in three layers, a constellation overview for the big picture, a satellite table for mid-level telemetry, and a detailed anomaly panel for digging in, so an analyst can go from "something's wrong" to "here's what's wrong and why" without switching tools.

Anomaly Dashboard — Orbital Elements

Detecting an anomaly is one step, documenting it is another, so a report generation modal lets analysts export telemetry summaries directly from the dashboard, and the whole workflow, detection to documentation, stays in one place.

The final deliverable was a working baseline prototype, presented to Amazon Kuiper's D.C. team, where a senior engineer specifically named the interface clarity and the pitch materials.

I also designed the handoff deck that went with it, covering onboarding, IP transfer, notes and considerations, and the AWS architecture diagrams the engineering team would need to pick the project up.

Handoff deck designed from scratch, walking Amazon's engineering team through onboarding, IP transfer, and architecture.