In the Human Interfaces Group (opens in new tab) at the Jet Propulsion Laboratory, we build software for people, just like you probably do. We believe in user-centred design, evidence over opinion, and the importance of learning quickly through sketches and prototypes. Time and budget are always constraints. Sometimes the speed of light is a constraint, too.
You see, some aspects of our work are a little unusual. We’re a federally funded lab that exists to accomplish the near-impossible on a regular basis. In short: enterprise software for space exploration.
We communicate with our spacecraft using the Deep Space Network: three sites across the globe with huge radio antennas. As I write this, dish 35 is downlinking data from the Voyager 2 probe. The data, travelling at the speed of light, currently takes 1.24 days to arrive.
Among many tasks for many missions, our group is working on new displays for DSN operators so they can better monitor, debug and correct any issues with data communication. It’s critical that they see problems quickly and can immediately jump to the low-level information.
We believe in measured automation. We design software for experts, but we need to make sure they’re using their brainpower to do their jobs, rather than for figuring out how to wrangle sub-par software.
The complexity of our missions and of our data are increasing. With Mariner 4, in 1965, you could plot the data by hand (which they actually did, at JPL). The Mars Curiosity rover is currently capturing an enormous amount of data. Mars 2020 will improve upon that again. We must produce software tools that substantially expand human capacity, or we’ll hit a ceiling.
When we do our job well, we get to expand the possibilities for science and exploration. Every day, we must focus on ensuring we are building the right tool for the job. We try to avoid guesswork by testing our assumptions and ideas as early as possible, and working with our customers throughout the entire process.
We ask ourselves a lot of questions: Who’s our audience? What are we trying to accomplish? Is the thing we think is a problem actually a problem? Does our solution effectively address the problem? Does our design embody our intended solution? Is the design usable by our audience in the context of their work? What’s our most dangerous untested assumption?
Prototyping for tiny user bases
We can’t A/B test our way through design decisions. Sometimes our entire user base is a handful of people working in the building next door. That level of access is great, and it’s pretty different from designing a web app for anyone with internet access.
So how do we know what’s right? We use a range of techniques to communicate what possible futures might look like. Long before we have detailed interface sketches, we use narratives and storyboards to show our ideas. We use paper prototypes and experience prototypes to evaluate people’s use of the tools we have yet to build.
We build software for humans. We design and build iteratively. There’s much more software running on the ground than on the spacecraft. It’s more straightforward to update ground software than flight software, so we can maintain a certain level of agility in deployment, as well.
At the moment, much of our work runs in a web browser, although we also look beyond the web. We’re currently building 3D immersive collaborative software for deciding what Curiosity, our newest Mars rover, does every day, and there are many more opportunities to use augmented and virtual reality for science.
These platforms are just beginning to be explored. Our intuition, and design and prototyping techniques, are much less useful in those new realms. We need new tools to build new tools.
Do you want to find out more about design at NASA? Steve Hillenius, UX manager and designer at NASA, will give a talk about astronaut autonomy through design at on 9 June. The conference also features talks from the likes of Aaron Gustafson, Rachel Nabors, Stephanie Rewis, Steve Souders, Josh Brewer and eight other great experts. Get today!