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, sensors onboard will start to monitor components on 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 operators
All of us were new to this area, so we decided to start our journey from understanding the user's needs, the rover operators. We first talked to engineers and operators, and then we conducted a vast amount of secondary research. Afterward, 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 detailed data to analyze the health condition of the rover.
3.
Troubleshoot when anomalies occur
When things go wrong, operators need to troubleshoot as soon as possible to avoid mission failure.
2. Define
Identify data flow
We developed a data architecture that illustrated the flow of information in the system according to the knowledge we gained from the research and interviews. 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 are the key elements of the telemetry interface.
Create 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 occurred 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 in investigating documented errors for troubleshooting.
Ideate interface layout
We initiated our ideation with Crazy 8 practice (coming up with eight ideas in 8 minutes). After synthesizing 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 detail. We explored various ways to present data on pages.
Iterate on wireframes
After figuring out the design direction, we moved on to Figma to build and iterate on the low-fi wireframes. Three of us could collaborate on Figma quickly and seamlessly, which enabled us to divide and conquer without spending too much time on synchronization.
Dashboard
We applied module design on the dashboard to give operators a holistic view of 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 the operators' investigation.
Feedback from operators
Throughout the design process, we kept testing our wireframes on operators and collecting feedback to improve our design. Here is some critical feedback that led to significant design changes later on.
1.
No "real-time" data
Due to the long-distance, there will be a 4-second delay on all data transmission, 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 period is more valuable for monitoring.
Single data points of sensors on the dashboard are not very helpful for monitoring.
Design changes
Instead of "real-time" data, we decided to present short-term historical data on the dashboard
3.
Troubleshooting requires data comparison
To troubleshoot anomalies, operators need to check data from multiple sensors at the same time 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 rover's bandwidth would be using is not wide enough to transmit all data at once, the data has to be sent within 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 for us. To deal with this, we have talked to operators, engineers, and conducted secondary research constantly to mitigate the knowledge gap.
2.
Work with multi-discipliary teams
Throughout the process, we have worked with multi-disciplinary teams, including engineers, operators, etc. Communication among groups requires "translations." We have learned many languages from 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 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.
Value proposition
1.
A holistic view of sensors on the dashboard informs operators of the status of the rover quickly.
2.
Detailed historical data pages enable operators to investigate abnormalities efficiently.
3.
Error marking process enables operators to document abnormalities for future study/investigation easily.
4.
All-embracing data on the error analysis page improves troubleshooting efficiency.
Next step
This is an ongoing project. In the next few months, we will conduct a usability test on operators in paper missions and keep iterating on the high-fidelity design according to the feedback.
Other work