Ellen Van Wyk
March 2020 - February 2021
La Cañada Flintridge, Remote
What is Observation Scheduling?
The schedule for a two-week portion of a mission timeline is discussed, modeled, and planned the two weeks prior to it occurring. During this time, 9 instrument teams, each with dozens of members, will ultimately define their wants and needs over the next 2 weeks. This information, along with the requirements of a number of other stakeholders, will all be absorbed by Mission Planners whose responsibility it is to allot resources and enact compromises, among other things. These resources include not only your typical battery or fuel, but DSN access, data rates, time, orientation, and more.
Ultimately the complexity of these plans means they must be run through modeling software to ensure their validity. However, this modeling is time consuming, outdated, and written in an internal code unknown to anyone outside of NASA - and most in NASA. This results in bottlenecking, as Mission Planners are of the select few with the modeling skills required to ensure schedule feasibility and optimization. To reduce spacecraft scientific planning bottleneck, this visual programming language will co-exist with its IDE counterpart to accommodate non code-friendly users. My time at JPL was spent largely on the research, planning, and initial design work of this visual programming language.
My Role in Depth
As a User Experience Design Intern, my role was 3-fold. First, I was to perform a heuristic analysis of existing internal visual programming tools. I would go on to evaluate these tools through Nielsen/Norman Group's defined usability heuristics, create a lengthy written report of my findings, and then present those findings to product owners, team leaders, and other stakeholders.
Next, I was to track down the constraints required for scientists to make complete observations, their frequency of use, and other nuances that may be difficult to define. This would include distance, time, celestial bodies, orientation, temperature required, and more. At the same time, and engineer and a designer would be turning these rules into user-friendly code.
Finally, I would use the information gathered from our research and heuristic analysis to create visual components to accompany this ever-growing language. These visual components would later be tested with users to ensure our definitions and constraints were aligned with their mental model of how an observation rule might be defined.
While a Design System for Europa Clipper had been newly created, my visual syntax work would ultimately be introducing functions and concepts that hadn't yet been required. With the existing system in mind, these newly created components would need to be easily implemented or altered by designers after I leave.
When arriving to Clipper, designer Ellen Van Wyk had recently created the foundation for what was to become an atomic research database that would house many years worth of JPL research. During my on-boarding to the team, I became one of the first user of this database. Pain points in that experience provided me the insight to create use-case collection workflows for seniors and any other intern who might follow.
These workflows consisted of validation checks to ensure data entry remained consistent and vetted by seniors before being presented to software teams and stakeholders. This vetting and strategy in information sharing is vital at JPL, a traditionally engineer-led company where design-led change can be tough to implement.
As I engrossed myself in the data, I gained enough understanding of our users to create the first ever set of personas for the Clipper software team. Not only would these be available for reference by designers for the foreseeable future, but I was able to introduce to engineers the concept of designing for users by highlighting key components of their behavior instead of referencing complex process flows. I would then write internal documentation for persona uses cases, and present that documentation to the team. Below is the workflow portion of one of our personas, "The Model Maker".
Ultimately, this is just a tiny part of what is going to end up replacing software that scientists and engineers at NASA have used to plan observations for decades. I really wish I could see what it turns into, although I likely never will. A small price to pay however, for the inspiration that I've received spending my time with amazing people - working on something much greater than myself.