02 RESEARCH
Secondary analysis.
We first had to understand mission requirements, rover functions, and operator roles.
Our initial step was to get a strong grasp on the project as a whole in order to understand user needs and our role. We started with client documents to understand data materials and other context necessary to design our interface. And there was one major finding that eventually led us to a series of primary research methods.
We immediately discovered the current interface is non-user friendly. More importantly, though mission goals and requirements are clear, operator roles are not properly defined.
02 RESEARCH
Primary methods.
To further understand and specify each existing role required for the mission, we conducted
expert interviews, journey mapping, and scenario generations to learn about required features operators need and what steps occur during each 2 hour communication window with the rover.
📑 Journey map
We conducted a journey mapping activity that shows all steps and visualizes what operators see and do. During this activity, our goal was to ensure that we record critical details of what actions are taken to accomplish mission tasks.
Initial journey mapping with operators
📑 Mission flow
Then we created a mission flow that summarized the stages and steps from our journey mapping. These are the prime actions from comm windows that we will be focusing on for our design.
Consolidated steps and stages
📑 Scenario generations
Generating scenarios helped us recognize and address possible edge cases that are likely to occur during comm windows. Varying scenarios are critical to consider to prepare for multiple errors and situations that operators might face.
Multiple edge cases
02 RESEARCH
Investigating Needs & Priorities.
Then, we focused on interviewing potential operators themselves, using what we know from our journey mapping and scenario generations. Though operator roles were not officially defined yet by the mission ops team, we had to grasp an understanding of possible operator roles for ourselves, as guidance for our designs.
🔍 Expert Interviews
We conducted interviews with MoonRanger's experts, including Thermal, Systems, Mechanical, and Software Leads. We also interviewed the Iris Lunar Rover team to get a sense of what data and features they need to see in the mission control interface.
🔍 Design Reviews
We held design reviews of mission control external sources, such as OpenMCT, Nasa JPL, and Epsilon-3 to understand how these systems successfully operate.
🔍 Best Usability Practices for Data-Heavy UI
With large amounts of data that will be uploaded and downloaded from the rover, we needed to solidify our approach to visualizing different aspects of data for operators to analyze.
There was a strong need for good data visualization to ease cognitive load on operators and verification for certain steps to reduce human errors.
02 RESEARCH
Defining & Interpreting.
Based on what operators need to do during comm windows, we made flow diagrams to map distinct operator roles and a hierarchy of these roles for our own understanding, giving us a clearer idea of what data each individual would need to see.
💬 Role Hierarchy
There are 6 defined roles running mission operations. This includes the navigation, data, science, and systems health officers reporting to the command officer, who then directly communicates with the flight director.
Operator task flow
💬 Mission Stages
These flow diagrams also helped us map out various command flows displaying what these operators do during the beginning and end stages of comm windows.
Beginning of comm window
End of comm window
02 RESEARCH
Prioritizing Features.
Now that distinct operator roles are defined, we were able to focus on certain features when designing our interface. Moving into the design phase, here are the prioritized features needed for operators to execute their tasks.
02 RESEARCH
Feature Prioritization.
After finalizing what mission operators need to see and what information they need to access, we listed required features discovered in our research to start understanding how the structure of our interface might work.
This helped us better understand how the main interface should be designed and which features should be put at the forefront to execute tasks quicker.
Features verified by operators
02 RESEARCH
Key Insights.
Our research yielded much information specific to subsystems or operators. We synthesized our findings and discovered three overarching insights:
✨
Features are inherently in groups
Rather than looking at each feature as its own separate entity, we were able to take groups of features as opportunities for development. Because our operator roles are uncertain, designing our interface around movable, logically grouped features could be a heightened “plug and play.” This kind of modularity could allow any given operator to find and use the features they need most.
✨
Operator roles are guiding, mission requirements are defining
While we had a sense of what operators might need to do, MoonRanger was not yet at that stage. We decided to focus our work around the actions that needed to be completed, rather than the people who may be completing them.
✨
We must accommodate both subject matter experts and novice
We found that the chosen and trained operators will be relatively new to the project, and therefore, we cannot count on them being subject matter experts. It’s imperative that we keep this perspective in mind when designing our interface.
03 DESIGN & ITERATE
Low-fi prototype.
Our research activities gave us a new level of understanding of the MoonRanger project as a whole, as well as where our main responsibilities will lie. Based on our insights, we have newfound design ideas. Heading into the first design iteration, we chose to focus on individual widget designs to group into sets of features. This would ensure we understood the operator experience at a micro and macro level before diving deeper into visual details and micro-interactions. Throughout multiple iterations, we also focused on opportunities for modularity.
+ Modularity
+ Early Stage Widgets
+ Side Navigation Bar
03 DESIGN & ITERATE
Mid-fi Prototype.
Based on our feedback from 1:1 interviews, we added new error screens and time scales to relevant pages. We continued expanding on modular screens and aimed for detail and usability using more consistent styles.
+ Error Alerts
+ Time Scales
+ Initial Design Style Guide
03 DESIGN & ITERATE
High-fi Prototype.
We discussed with subsystem leads and NASA experts to evaluate our mid-fi designs from an operator perspective. After mid-fi iterations, we discovered changes to consider moving forward.
Modularity is low priority and operators need fully-equipped screens to see all relevant data.
Diving into high-fi iterations, we focused on widgets containing all relevant data desired by individual operators. Our goal was to finalize designs both functionally and visually for handoff to the development team. We also focused on optimized architecture and a design system that refines the visual design of our interface.
+ Design System
+ Optimized Architecture
+ Fully-equipped screens
- Modularity
04 VALIDATE
Paper Mission Testing.
We conducted a paper mission, essentially, a mock mission. This allowed us to see how our designs held up when faced against real mission tasks.
Paper mission testing with mock operators
05 DOCUMENT
Widget Documentation.
We provided a detailed documentation for the development team, and ourselves, to keep track of our work and to ensure no meaning would be lost.
