UX · Product Design · Data Visualization
A satellite intelligence dashboard that turns orbital telemetry into something analysts can act on in seconds.
While our main point of contact was Yash, in reality, I idenitified three user groups that made up the ecosystem of this tool:
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 hold at once.
Before this tool existed, catching any of those meant engineers had to manually scan dozens of telemetry graphs and compare orbital elements one by one, then oad the data, pull up the graphs, look for anything that doesn't fit, and investigate. All by hand, across multiple tools.
How might we make dense orbital telemetry readable at a glance without losing what makes the data trustworthy?
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. It wasn't about showing more data, more about making the right data impossible to miss.
The vast majority of my team was ML engineers, backend developers, product leads. There were two designers, one of them me.
I led overall visual direction, dashboard architecture, and 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.
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.
We sat with Yash's team long enough to notice patterns. 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
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. Not to ship it, but to feel out whether that language actually fit what we were making.
Mock screens built from the Alexa style guide. A starting point to react to before figuring out what we actually wanted.
From all of that, three goals shaped how we approached the build. They came before any screens.
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.
Referenced dashboard models
My co-designer and I spent a lot of time thinkinf about the clarity of our visualizations; if they looked like they belong in a satellite tool and if they could actually help someone spot a problem fast. I found the most useful question wasn't "does this look right." It was "would someone trust this at a quick glance when something's wrong."
Revised designs: stepped away from Amazon's component library toward something simpler and more buildable.
Mid-fidelity explorations: layout decisions that started to feel real.
We ran three feedback sessions with Yash where we found out which visualizations were confusing, where the anomaly indicators fell short, 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; though we weren't finished, it was important to make something legible to a stakeholder. When developin the slide design, I thought a lot about how I wasn't just showing work, but I was building the package that Yash would use to react to it and our professional capability as a student group.
Pitch deck designed from scratch. 19 slides built to walk Yash through the proposal.
Yash's feedback 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 ship in the very limited time we had. We basially started over, rebuilding the information architecture from the ground up and figuring out the structure before touching any screens with a design system re-built specifically for this tool.
Four modules, each mapped to a distinct phase of what an analyst actually does.
We settled on a scheme much darker by necessity, but with intentional color. The data is already dense, so color is used sparingly (calm baseline, loud signal). Every decision traces back to one constraint: the interface can't add to the noise.
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.
The version we landed on opens on three plain numbers: running, flagged, under review. The most important question gets answered the moment you open it.
Length is faster to parse than digits across hundreds of rows. That part still feels right to me. But the bars were also one of the harder components to implement. I found myself asking whether they were serving the user or serving the design. What we landed on is simpler, more buildable, and more honest about the constraints we were working in.
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. An analyst can go from "something's wrong" to "here's what's wrong and why" without switching tools.
Detecting an anomaly is one step. Documenting it is another. A report generation modal lets analysts export telemetry summaries directly from the dashboard. The whole workflow, detection to documentation, stays in one place.
General Dashboard (summary + scatter), Parking Dashboard, Anomaly Dashboard. V1.0 dark theme.
The drill-down panel: all relevant signals for a single anomaly, without navigating away from the dashboard.
The final deliverable was a working baseline prototype, presented to Amazon Kuiper's D.C. team, of which their engineer specifically named the interface clarity and the pitch materials. After that, the project moved to Amazon's engineering team to build out.
I also designed the handoff deck that went with it, another one I built from scratch, 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.
