Design for a space mission
Design the telemetry data interface for Iris Rover, which will land on the Moon in 2021.
Iris rover is the first private academic rover developed by Carnegie Mellon University, NASA and Astrobotic, and will land on the moon in July 2021.
Problem
When the Iris Rover lands on the Moon and all sensors onboard will start to wither collect data or monitoring the rover. How could operators monitor the health of the rover and troubleshoot when anomalies occur?
Solution
A telemetry data dashboard is created to present operators the data from onboard sensors and also enables operators to look into detailed data and troubleshoot anomalies.
My role
Conduct design research
Define features and workflows
Iterate on wireframe designs
Deliver design specs
Team
Diana Zhan
Shan Wang
Duration
Sep, 2019 - Present
The Process
1.
Discover
- Learn from stakeholders
2.
Define
- Identify data architecture
- Categorize data
- Prioritize features
3.
Design
- Initiate design with sketch
- Define workflow
- Iterate on wireframes
- Move on to high-fi deisgn
4.
Deliver
- Create design specs
1. Discover
Learn from stakeholders
All of us were new to this area, and we decided to start our journey from understanding the needs of the user, the rover operators. We first talked to engineers and operators, and then we conducted a great amount of secondary research. Afterwards, we were more confident in moving forward.
“ ... the raw data can be helpful for post-mission analysis, but the team needs to monitor the inferred value during mission to ensure proper performance of all criticle components.”
- Lou, System Engineer
“ The main goal of the telemetry interface is to monitor the overall health of the rover, and warn the team if something goes wrong.”
- Raewyn, Flight Operator
“ ... a lot of times the failures require human analysis and cannot fully rely on auto-generated error messages.”
- Connor, Flight Software Engineer
What operators need?
1.
Monitor the overall health of the rover
Operators need to check the data from dozens of sensors onboard to monitor the health of the rover.
2.
Check detailed historical data for analysis
Operators need deatiled data to analyze the health condition of the rover.
3.
Troubleshoot when anomolies occur
When things goes wrong, operators need to troubleshoot as soon as possible to avoid mission failure.
2. Define
Identify data flow
According to the knowledge we gained from research and interviews, we developed a data architecture that illustrated the flow of information in the system. This structure reinforced our understanding of the data.
Categorize data
Based on the data structure, we categorized data from all types of sensors into different sections. Data in the “Integrated Visualization” and “Error Messages” columns would be integrated into the telemetry interface.
Ideate and prioritize features
We further examined the data categories and came up with a more specific feature list for each data category. We then prioritized the features to guide the design later on.
Align features with user needs
1.
A dashboard presenting a holistic view of sensors
Give operators an overview of current rover status
2.
Detail pages showing historical data for analysis
Enable operator to further investigate the rover by delivering historical data of onboard sensors
3.
Error tagging and analysis for troubleshooting
Help operators record and further analyze anomalies that occured during the mission
3. Design
Generate workflows
Based on user needs and features, we moved on to generate workflows to clarify the interactions.
Monitoring
To show operators a holistic view of data and to navigate them to detailed historical data pages if necessary.
Error tagging
To guide operators to document anomalies that occur on sensors step by step.
Error analysis
To assist operators to investigate documented errors for troubleshooting.
Ideate interface layout
We initiated our ideation with Crazy 8 practice (coming up with 8 ideas in 8 minutes). After synthesizing of our ideas, we came up with the dashboard design as follows. We applied a module design and arranged the data categories according to the prioritization based on our research.
Design user interface
After figuring out the layout, we started to design the interfaces in details. We explored various ways to present data on different pages.
Iterate on wireframes
After figuring out design directions from the sketch, we moved on to Figma to build and iterate on the low-fi wireframes. Three of us could collaborate on Figma easily and seamlessly, which enabled us to divide and conquer without spending too much time on synchronization.
Dashboard
We applied module design on dashboard to give operators a holistic view on the rover. By presenting real-time data only, we wanted to minimize operators’ effort on perceiving the rover status.
Detail page
By listing all sensors in the same category vertically, the detail pages enable operators to investigate and compare data across sensors easily. On detail pages, operators can also edit the “safe zone” threshold for specific sensors.
Error analysis
We listed all errors on the left and detailed data graphs in the middle for the convenience of operators investigation.
Feedback from operators
Over the course of the design process, we kept testing our wireframes on operators and collecting feedback to improve our design. Here are some key feedback that led to big design changes later on.
1.
No "real-time" data
Due to the long distance, there will be a 4-second delay on all data transmitted back to earth, which means there won't be any "real-time" data.
Design changes
Show the "last updated time" at the top of the screen.
2.
Historical data in a short time period is more valuable for monitoring.
Single data points of sensors on the dashboard are not very helpful for monitoring.
Design changes
Present short-term historical data on dashboard instead of "real-time" data.
3.
Troubleshooting requires data comparison
To troubleshoot anomalies, operators need to check data points from multiple sensors at the same time period for investigation.
Design changes
When an anomaly occurs, all data at the time, including images, will be saved to the error card.
A false alarm of bandwidth limitation
Once the team realized that the bandwidth the rover will be using is not wide enough to transmit all data at once, which means the data has to be split into multiple parcels. The asynchronous data will bring a lot of challenges in data visualization. Fortunately, we solved this issue by partnering with a company that will offer us extra bandwidth during the mission.
This was just a brief interlude. But we have come across many challenges over the course which makes it an exciting journey.
Deal with challenges
1.
No experience in space missions
Lack of experience in space missions is a big challenge to us. To deal with this, we have talked to operators, engineers and conducted secondary research to mitigate the knowledge gap.
2.
Work with multi-discipliary teams
Over the course, we have worked with multi-disciplinary teams, including engineers, operators and etc. The communication among teams requires "translations". We have learned many lanuages from the others.
4. Deliver
Move on to high-fidelity design
After rounds of iteration on wireframes, we finally move on to the high-fidelity design. In this phase, we have worked closely with the Cosmos team which determines the overall look across all interfaces by providing components, colors and styles. On the other hand, we have also kept updating our design according to the feedback from developers.
Dashboard
To give operators a holistic view on the status of the rover.
Detail pages
To enable operators to do further investigation on sensors.
Error tagging
To guide operators to document errors or anomalies during the mission.
Error analysis
To help operators investigate errors by showing data across different sensors.
Next step
This is an ongoing project. In the next few months, we will conduct usability test on operators in paper missions and keep iterating on the high-fidelity design according to the feedback.
Other work