Desktop App Design + System Design + Space Exploration
Project Timeline: 5 weeks
(The project has been since renamed to Iris)
A robust structure of image storage and categorization to enable points of interest to be identified and plotted in order to safely navigate lunar terrain and facilitate scientific missions.
How might we design a system to help a rover navigate unfamiliar lunar terrain with limited resources?
The rover navigates through lunar terrain by capturing images after every maneuver which results in an overwhelming amount of images during the mission. How do we store all the images captured in a way that is valuable during and post operations? In addition to dangerous obstacles, it must avoid areas of shadow due to its dependence on the camera. How do we design an interface to minimize errors and allow users to recover quickly under all the technical constraints? How do we identify the points of interests and threats?
Received 79.5 million dollars from NASA.
Navigating through unknown terrain with a camera results in an abundance of images that need to be filtered. How do we organize the information in a meaningful way that could minimize the risks of a high stakes mission?
A flexible architecture of image storage that allows the categorization of images in the form of cards. The cards are stored for post-mission purposes and visually represented on a map in real time to manage any risks that could end the mission.
We created an information architecture of categorization for the images that spanned across the map and the image viewer feature of the interface. Most of the images are used to navigate the regolith; however, images that are of importance are tagged using the Point of Interest (POI) system. The POI categorizes the image as an attraction, shadow or obstacle and gives the ability to specify the importance and enter details about the POI. Attractions are green, obstacles are red, and shadows are areas to illustrate the dangers of obstacles and areas of shadow. To understand the application of this system, it is important to have some understanding of the design team (TeleOps) and the structure of the mission.
Tele-Operations Communication Diagram
Landing a rover on the moon is no easy task and as a result, it was a large interdisciplinary team that all had one mission: To successfully land the rover on the moon. The diagram below illustrates the complex team organization that was involved in this mission. The key for me was to understand enough about the ecosystem to enable other stakeholders to carry out their goals.
The TeleOps Design Team
So where do I fit into this ecosystem? I am part of the TeleOps design team that was tasked to create the interface for the ground team directly controlling the rover itself. The cosmos system team was responsible for creating a design system and the telemetry, map, and image viewer teams were all responsible for their own interface. Although I was assigned to the map team, I worked on a feature that spanned over the Image Viewer team as well. This added an additional challenge of keeping consistency between two interfaces with completely different goals.
With the complex interactions between the team working behind the scenes, the mission was "simple": To successfully land the rover on the moon. To isolate and simplify the process, the diagrams below illustrate the tasks related to the interface design of the TeleOps team.
Phase 1: Arrival on the moon
Phase 2: Deployment of the rover
Identify points of interest that are attractions, obstacles or shadows
Support scientific and blast ejecta analysis during the mission
Document and organize the data for post-mission analysis
Key features of Point of Interest (POI) cards
The key features of the POI system are the two versions of the POI card: collapsed and expanded. The collapsed version is used in the map interface and only displays the essential information about the POI. For example, the attraction only shows the system-generated name, the importance of it, tags and the dimensions. The expanded version has additional metadata and a collection of images of the given attraction.
Visual designs finalized by Haley Park
The 3 labels for all images are attractions, obstacles and shadows. For obstacles and shadows, the importance is always at the highest level of 3 as both could result in the premature termination of the mission. However, the same system is used for consistency despite the lack of need for a level 1 importance of shadow. For attractions, the importance can help indicate and prioritize the most interesting artifacts for the scientists. Originally, shadows were a different color to obstacles distinguish between the two; however, this evolved to simplifying the cognitive load and using red to represent danger and green to represent a safe POI. Shadows and obstacles are differentiated through shape instead of color.
How do the POI cards fit into the bigger picture?
Designing the structure behind the POI cards had substantial impact on both the image viewer and map team as it determined how the majority of data was stored and organized. Although I did not work on the flows of integrating the POI cards in the image viewer, it was rewarding to see the impact I made.
The image viewer team (Helen, Chloe and Jay) did an amazing job of integrating the POI cards. The detailed out flows that created the cards themselves and managed the accumulation of POIs at the higher level.
Create the POI card
The creation of the POI card was the first step in introducing it into the system. This process included selecting the correct image and details of the POI (category, importance, tags etc).
The POI cards are primarily featured in the map interface where they are utilized to document, organize and visualize any points of interest. This integrated to the existing capabilities of the map of planning and editing routes. The visualization of the POI is essential to the ability to circumnavigate any attractions. I designed the added functionality of sorting, tagging and the separation of mapped and unmapped POI cards.
The ability to store the influx of information about identifying new POI in a systematic manner.
The cards allow the high volume of data to be quickly parsed through with filters, tags and mapped elements.
The documentation and organization of the information is not sufficient alone and is plotted on the map interface to provide visibility.
Plotting a POI
After I had stopped working on this project, the current map team implemented the flow of visualizing the points of interests on the map. This helps users to maintain a mental map without the need of extraneous moves when each move is costly.
Circumnavigating an attraction
Another feature that the POI system enabled was the ability to circumnavigate an attraction. The map team (Hailey Motooka, Vicky Zhou, Celine Chang, Michelle Chen) executed this flow as well as tackling other challenges like absolute and relative positioning. This circumnavigation feature is essential to collecting images of blast ejecta for analysis.
Technical constraints of space travel
There were various constraints that were unique to space travel that posed challenges to the solutions. The user’s ability to recover from errors were much lower and required these solutions to be as fool proof as possible.
Determining the information architecture
After interviewing engineers and talking to other leads of the project, many meetings were held to prioritize the types of information that should be on the cards. The information was categorized into 3 tiers:
Organizing POI Cards
After determining the underlying structure of the POI cards and what information was essential, the next step was to visualize how it would look and how it would be organized. The amount of information that is already existing on the map interface resulted in the creation of two versions of the POI card: collapsed and expanded. The expanded version would be in the image viewer which is the main tool used to analyze and categorize images.
Rover in Action
The nature of a space mission presented various unique design constraints that I had not previously considered. In a way, I think every product should be designed with similar constraints as it requires you to really understand what feature you’re building, why you’re building it, and how to make it as foolproof as possible. Furthermore, another challenge of this project was working with ambiguity to a whole other level. Not only were mission goals constantly changing, but it was near impossible to understand the whole project because of the scale of the team and different departments (mechanical engineering, astrophysics, flight operator, etc). Although intimidating, it was fun to learn about such different fields and what was important to them. At the end of the day, we were all solving the problem of how to successfully land the rover on the moon in 2021.
Allow users to easily identify problems and present clear steps to solve the problem.
You won’t always know everything. Learning how to understand enough to do your job is a skill.
Be resourceful. Be intentional about what you’re designing and why you’re building it.