NASA SUITS

Working as a team

NASA SUITS is a multidisciplinary project. Not only are we working with another college, Columbia University, we are also a team composed of engineers and designers. Our team is so varied that we had a representative from eight of the nine different colleges at Wichita State University. Our widespread experiences became one of the core strength of our team. We pooled our knowledge from many different sources to make a high-quality and well-rounded design. However, our widespread base meant that we had to communicate deliberately and clearly with each other so that we'd all be on an equal level of understanding. As a team, we worked together to make the best possible design that provided all of the essential data that an astronaut could use while not overloading them with information.As a game designer, I consider myself as in between a designer and an engineer. I believe that video games are an art and a science, after all. My experiences meant that I’ve already developed a lot of both the languages of design and engineering. I found I was able to comfortably communicate with both designers and engineers, so when it came time to elect a team lead for the CosmoShox, I volunteered. Being team lead meant that I had to oversee a lot of the proposal and development process. I delegated roles to team members based on their strengths, and I filled in crucial gaps where I could. I took the feedback we received on the proposal to heart, and I communicated to the rest of the team what needed to be done to apply that feedback. I took on a lot of responsibility as team lead, and I did my best to live up to my team member’s expectations.

Image of our NASA SUITS Team, CosmoShox at the Cosmosphere in Hutchinson, KS.
Me on far left.

The Journey Map

As a team, before we put anything down on paper, we had to understand how our user interfaces were going to be used. To do this, we made a journey map. The journey map outlined how our HUD would be used on an extravehicular activity (EVA). This gave us the perspective of our users, and it informed the rest of our design. Instead of asking, “What do we need to make?” We started to ask ourselves, “What would we want our UIs to do for us?” This perspective prepared us for designing UIs with a human oriented approach.For instance, through our journey map, we discovered that we wanted astronauts to interact with our designs through voice command. This way, they could use their hands freely. We also found that eye tracking technology would be impaired by solar conditions on the lunar south pole. The journey map informed our decision and helped us discover what we wanted to do. Once we had solidified our goals, we started drafting our designs.

Images of our Journey Map.

The Design

After discovering what we wanted our designs to do, we dug into researching our designs. This way, our design decisions were informed, and we could back up the deliberate decisions we made. We looked into design theory and cognitive load theory, and we looked at the technology we were using. I looked into how we would use our designs with Unreal Engine. I checked that the ideas we were proposing were feasible by digging into Epic Games’ documentation, and learning everything I could when it came to working with AR in Unreal Engine. Once our research was complete, we were ready to start developing our designs.Like making a thumbnail before a painting, we made sketches of our designs on paper before our experienced designers implemented them into Figma. Our team, both designers and engineers, met together at coffee shops and started sketching out exactly what we wanted to make. After sketching, we’d discuss what worked and what didn’t. Then, we’d start sketching again. This rapid iterative approach allowed us to test ideas fast and hammer out a design that everyone was happy with, across all of our disciplines. Once our designs were solidified, we were ready to finish our proposal.

Sketches of our HUD designs and our rover designs.
Sketches by John Mulnix and Me.

The Proposal

When it came time to finish our proposal, we were prepared with our perspective set, our research done, and our designs finalized. Our proposal was about putting our work into words. We split up the work according to our roles and worked together to get everything done. We would meet weekly to double check each other’s work to make sure quality was consistent. Whenever we finished a draft, we sent our work to our faculty advisors for feedback.Feedback was critical to the proposal process. It allowed us to see our work from a new, experienced perspective, and it empowered us to adapt our work into something better for it. In a project like this, it’s easy to lose track of what’s most important. Feedback was the key that kept us innovative without letting us go astray. Every time we received our feedback, we rewrote what didn’t work and strengthened what did. We repeated this process multiple times until turn in day on October 31st. After a long month of waiting, on December 6th, we finally heard back from NASA that our proposal was accepted!

Figma designs done by Shaybree Haynes, Janis Hwang, and Jude Khaldi.

My Responsibilities as Team Lead

As team lead, I had to wear many hats since a lot of responsibility was put on me to make sure that development was going smoothly. We had 4 sub-teams, an Unreal Engine Team, a Autonomous Navigation Team, a Design Team, and a Human-In-The-Loop Team. Our development time was only 5 months between when our proposal was accepted and our final deadline, so It was my job to make sure that there was constant and healthy communication between all sub-teams and that no bottlenecks were occurring. We used two tools to do this, Agile Product Management and consistent communication.As a team, we used Agile Product Management to organize our development. This way, we could be adaptable and respond to design changes as we developed. We researched and tested as we developed, so it was key to make sure that our development teams could adapt to the new designs. We underwent a lot of formal and informal testing, and we got a lot of useful feedback, so we knew we had to implement it to make our UI the best it could be. Our two-week sprint flow was incredibly useful for this. We could adapt our designs while keeping our development team on track without wasting development time. For example, one trick we'd use is that our design team would be one or two design sprints ahead of our development teams. This way our development teams would always be working on the best, most recent designs with all of feedback applied to it.As team lead, I took role as product owner. This meant I had to , and I was in charge of keeping it up to date. Anyone could glance at the board and immediately see what everyone else was working on, so I frequently kept it up to date. This was one of the most crucial parts of our communication. This enabled Transparency which was one of our greatest strengths as a team. We kept track of both a physical and digital Kanban board. I had to make sure that our sprint goal was relevant to the entire team and that everyone was working on what they were assigned. This way all of the separate teams could know what the others were working on.With all of these tools in hand, our team was able to communicate and understand what everyone else was working on. This way, we would never overwrite or nullify each other's work. It was a crucial part of our flow and a major part of my responsibilities as team lead. Communicating with every CosmoShox member has been my favorite part of development by far.

Images of me working with the team.

Images of our physical and virtual Kanban boards.

My Work as a Developer

On top of being team lead, I was also an Unreal Engine developer for our team. I worked alongside my development-buddy Annastachia Brown to bring our designs to life. Our main challenge was running the Unreal Engine UI alongside a Python server that ran our critical navigation algorithms, a telemetry stream provided by NASA, and a virtual simulation of the moon called DUST. There was a lot of communication back and forth, and our Unreal Engine UI was at the center of it since that is where the user input their commands. We had to develop it in a way that was both intuitive to them and feasible for our team to make.To make our system work, I first built a system that could parse JSON data inside of Unreal Engine. This system took data in from the NASA provided telemetry server, reported when values were outside of nominal ranges (e.g. Oxygen Storage less than 20%), and displayed it to the user in a readable format. These warnings can also be sent out via a server to the HUD that Columbia is building.Another system I built was sending commands to a virtual rover inside of DUST. To do this, I had to research into UDP to send commands to DUST. There wasn't a default way to do this in Unreal Engine, so I dug into C++ and made a script that could send all the commands we need. Using this system, we sent commands to DUST to control a rover inside of it. We also used the parsed data from telemetry so that the rover could autonomously navigate between any two points utilizing automatic hazard avoidance.To work on this project, I had to work within many different aspects of development that I had never done before. I had to learn about networking and servers, Unreal Engine UI, and autonomous navigation. I'm just grateful for the chance to learn so much, and I'm grateful for the fantastic team I get to grow with.

Images of our in-development project.