To enhance mission efficiency, the The Mars 2020 team at NASA Jet Propulsion Laboratory (NASA JPL) is working to reduce rover daily planning time from 12 to 5 hours. Rover planning at JPL is a complex decision-making process, requiring consensus among various scientific and engineering teams to maximize discovery while maintaining the safety of the rover.

How might we enable scientists to make better decisions by augmenting their understanding of Martian weather conditions?

Following our exploratory round of research, we felt we’d found a particularly rich area to focus our efforts on. In order to reflect this, we revised our problem statement to focus on aiding scientists better understand and utilize tau information.

How might we help scientists understand and predict the impact of atmospheric opacity (tau) on instrumentation and data?

Facilitate Debate

The advancement of scientific knowledge stands to benefit from disagreement as dissent breeds productive debate in order to reconcile conflicts. Our tool needs to facilitate healthy discussion between differing points of view in order to drive scientific advancement.

Prioritize Customization and Flexibility

Scientific discoveries stem from finding novel ways to analyze and interpret data. To promote further exploration, the tool needs to provide scientists the ability to explore a dataset in various ways without disrupting existing work preferences.

See Through the Same Lens

Scientists are using their own tools and this could lead to misunderstandings about the meaning of their output. As a result, enabling shared mental models is crucial in order to ground conversations.

Show How Things Fit Into the Bigger Picture

Scientists and engineers should understand how their work impacts each other and the overall mission. This can be done through contextualizing data to provide a comprehensive view of the situation.

Stay Transparent

Methods: Brainstorming, Sketching, Storyboards

Storyboards

Of our 400 ideas, we chose 6 concepts to explore more deeply and assess whether they would help solve the pain points. Storyboards helped us apply proper contexts to each idea, learning where the concept may fall short and what kind of interactions were needed to make the experience happen. Many of our storyboards ended up informing our prototype, like the Tau Mapping and Instrument Health concepts. Others concepts were more aspirational, but still informed our later design. For instance, Mars Globe combination of snow globe and crystal ball to help scientists visualize tau levels. While we didn’t build this concept, it did inspire both our Rover View and Forecast features in our final design response. 

Methods: Paper Prototyping, Rapid Iterative Testing & Evaluation (RITE), Remote Usability Testing

As the timing of the project only gave us a few short weeks to test and our the NASA scientists and engineer participants were geographically dispersed and difficult to recruit, we opted to utilize the RITE (Rapid Iterative Testing and Evaluation) method. This method allowed us to test new ideas relatively quickly while making changes as problems became apparent, maximizing our time with the NASA team members. This also meant that we didn’t have well defined low/mid/high fidelity prototypes as they were in constant iteration and fidelity naturally evolved along with the design. The key feature iterations are highlighted below.

Iteration 1: Instrument Panel

The goal of the instrument panel is to allow scientists to quickly identify when is the best time to use an instrument. Green means it’s safe to use and red means it’s harmful.

Iteration 2: Rover View Panel

The goal of the rover view panel is to allow scientists to simulate what images would look like given the predicted tau value. Scientists can avoid taking images that would not be usable and save rover battery for other activities.

Iteration 3: Seasonal Tau Panel

The goal of the seasonal tau feature is to give scientists access to historical tau data so they can quickly assess data trends and patterns overtime.

Incremental progress is critical

We originally set out to create a tool NASA JPL would actually use rather than a speculative design piece. We felt this would be more inline with what the client (NASA) was expecting, easier for our participants to see the value in, and more rewarding from a personal perspective. While we went in expecting to create an entirely new tool, what we actually created was a template for incremental progress that the NASA team could use for further design explorations. There is currently no tool that takes weather into account for rover activities, but thanks to us NASA has a point of reference and base research to begin looking at solutions outside of just atmospheric opacity. This design could be utilized to forecast effects of other weather conditions on instruments like pressure, humidity, or wind.

Narrow your problem space

As a result of clearly defining our problem early on, we were focused and better able to coordinate our efforts. As we continued into the design process, we realized that by finding and defining our space early, we were able to concentrate on solving a specific problem rather than spend more time ideating on a broader range of problem spaces, which would have consumed our already limited time. This also allowed us to explore multiple ways of solving the same problem, which became a boon when we realized that some approaches weren’t feasible. Rather than go back to the drawing board, we were able to substitute solutions we’d already presented and discussed. I’m convinced that being ruthless with our problem definition was one of my teams best decisions.

Know your audience and speak in their language

One thing that our team did effectively stepping into the project was preparing ourselves with technical knowledge and learning the lingo at NASA. This helped us build rapport with scientists quickly during the research phase, leading to more productive conversations. This was even more apparent when we began getting peer feedback from within our cohort; when we spoke with our peers about our project there had to be a time allowance for education on Martian meteorology. If we had asked our NASA participants to do this for us, we would have wasted valuable time and the quality of our interactions would have suffered.

Avoid remote testing early prototypes

Given the constraints of the project, we had very few NASA team members in the Seattle area to test with in-person. This meant that we had to move toward digital prototypes more quickly than I’d have liked. This limited our ability to test interactions in a low-commitment environment, which meant there was a greater threshold for implementing changes to the digital prototype. In-person testing also facilitates more context to the feedback you’re receiving because you are able to interact with the participant more. If I could, I would test early-stage prototypes earlier and with more people so that we could iterate more quickly on our early prototype and solve those problems faster.