Satellite orbit design & planning
Making a highly technical satellite operations tool more accessible and usable through thoughtful design.
Situation
Brief
Spaceguard is a satellite and orbit planning software developed by Exotrail for military operations that helps users track nearby objects and identify when those objects may be monitoring their own satellite, something that’s increasingly important as space becomes more active. Mission planners and simulators rely on it to track and manage satellite trajectories, simulate orbital tracking scenarios and explore counter-surveillance strategies. My role in this project was to design a feature that improved data visualization and interaction, enabling users to efficiently screen and analyze satellite data.
Challenge
Defence operators needed a better way to visualize object trajectories and understand their relationship to their own satellite. Spaceguard was already in use, but the interface was highly technical and hard to interpret. My goal was to redesign key parts of the tool to make it more intuitive and accessible, so operators could quickly understand what was happening and make decisions with confidence.
A unique project process
Designing without access to data
This was one of the most challenging projects I’ve worked on—not just from a UX standpoint, but from the technical complexity involved. To design effective interfaces for Spaceguard, I had to quickly get up to speed on core concepts in aerospace and orbital mechanics, including orbital elements and orbital determination. While I wasn’t expected to be an expert, having a working understanding of these concepts was essential to making informed design decisions.
​
With no user interviews or behavioral data available, I leaned heavily on design heuristics and UX laws to guide my work. I focused on:
-
Simplifying dense information through clear visual hierarchies, applying Jakob’s Law (users spend most of their time on other sites, so familiar patterns help reduce friction) and Miller’s Law (limiting cognitive load by chunking information into digestible pieces).
-
Grouping related elements using the Law of Proximity and the Law of Similarity, which helped users mentally organize complex data at a glance.
-
Reducing cognitive load by minimizing technical jargon and surfacing only the most essential information, guided by Hick’s Law (simplifying choices to speed up decision-making).
-
Designing for clarity and speed, leaning on Fitts’s Law to ensure key actions and interactions were easy to locate and use, especially in time-sensitive scenarios.
I collaborated closely with our orbital mechanics engineer to validate the accuracy of visualizations, and with our PM to ensure we were prioritizing the most meaningful use cases.
Identifying problem areas
Navigating technical challenges and uncertainty
Redesigning Spaceguard came with some unique constraints: because our end users included military personnel, we couldn't collect direct feedback without compromising sensitive information. To work around this, I reviewed anonymized screen recordings of user sessions—silent walkthroughs of how operators interacted with the tool in real-world scenarios.
​
From these observations, I focused on identifying friction points: areas where users paused, seemed to hesitate, or clicked around repeatedly. I paired this with internal discussions with the PM and orbital mechanics engineer to clarify functionality and prioritize usability issues.
What emerged was a clear need for:
-
Simpler, more digestible visualizations of object movement and proximity
-
A clearer hierarchy of information to support quick situational awareness
-
Reduced reliance on dense data tables or technical terminology
Iteration & Collaboration
The first round of designs I delivered completely missed the mark
I thought I understood the problem, but once I shared my early concepts with the team, it became clear I’d misunderstood key parts of the functionality and oversimplified some of the logic behind the tool. The feedback was honest and direct, which I appreciated—and it was a turning point in the project.
​
From that point on, collaboration became a lot stronger. I made a conscious effort to ask more questions, clarify assumptions early, and keep communication open with both the PM and the orbital mechanics engineer. Our working rhythm became more fluid and collaborative, and the designs improved with each iteration.
​
To strengthen my understanding and test my ideas, I also interviewed other team members across the company—people who weren’t the end users but had relevant domain knowledge in satellite mechanics. These conversations helped me validate design logic, spot gaps in my thinking, and ensure the interface aligned with the real-world behavior of satellites.
I also stayed in close contact with the developer to ensure that the designs were realistic given our technical constraints, and that we could deliver a user experience that was both usable and feasible.
​​
Early wireframes missed the mark—key interactions were unclear, and I hadn’t fully captured the logic behind the tool. After getting direct feedback from the team, I took a step back, asked better questions, and worked more closely with the PM and orbital mechanics engineer. Each round of iteration brought more clarity, both in the design and in my understanding of the system.
UI and visual design considerations
The UI was largely out of my hands due to a tightly regulated budget and the use of a standardized component library. Aesthetic polish was considered an extreme “nice to have,” not a requirement. As a designer, that was tough—especially coming from environments where strong visual design was a priority. But this experience pushed me to focus on what truly mattered in the context: usability, clarity, and speed. It was a reminder that not every project needs to be visually refined to be valuable—and that good UX often means working within limits, not around them.
When there is no allocation for aesthetics in the roadmap
Final results and next steps
The redesigned Spaceguard interface was a significant improvement over the original. Internally, the team noted that it was easier to understand, better aligned with user workflows, and more visually cohesive. The work laid a solid foundation for future iterations and helped standardize how complex orbital data could be presented in a more user-friendly way.
​
For me, this project pushed my design skills in new ways. I had to navigate technical subject matter, strict confidentiality, and a lack of direct user access—all while still advocating for clarity, usability, and human-centered design. It reinforced the value of asking good questions, validating assumptions early, and leaning into heuristics when data isn’t available.
​
The updated version has since been used in several internal simulations, and feedback from the team has informed ongoing development.
