Hello World

Tait Wayland
Nasa Capstone 2018
Published in
5 min readFeb 13, 2018

Pardon us! We’ve been here for a month and haven’t introduced ourselves.

Alright, admittedly we need a better group picture. Scout’s honor, we will have one before this project is done.

We’re all part of the Masters of Human Computer Interaction at Carnegie Mellon, and we have the pleasure and honor to work with NASA for our capstone. We’re all pretty stoked to have such a cool client, but we’re equally stoked to work with each other. Here’s a brief background on all of us:

Ansaria Mohammed

Ansaria Mohammed — Research Lead

Hopes to get her hands on some astronaut ice cream…for research

Frank Teng

Frank Teng — Research Lead

Cried during the movie Armageddon (he was 6)

Ken St. Clair

Ken St Clair — Product Manager

Might have named his dog after the Fermi Paradox.

Melodie Yashar

Melodie Yashar — Design Lead

Like, isn’t that obvious from the picture?

Tait Wayland

Tait Wayland — Tech Lead

Major fan of doggos.

We have a team name also, Team C-137. Because, well, Rick and Morty.

“What on Earth is a WAD?”

Our prompt is to improve WADs — Work Authorization Documents. Basically, they’re instructions that people at NASA use to build things correctly. What do they use WADs to build? Oh just spaceships and the ground hardware that those spaceships rely on the be launched into space, no big deal.

Our clients are MHCI alumni, so we are relieved to not have to evangelize design thinking. On the flipside, the bar is raised for what constitutes good deliverables when your client literally does your job. The clients flew in from [A NASA FACILITY THAT IS REDACTED] and we met with them several weeks ago. We learned more about the domain, and the stakeholders therein. We also learned about the HCI group at NASA, its history, and the history of the legacy capstone partnership they have with Carnegie Mellon.

We learned that NASA has not done much user research in the context of WADs. This gives us an opportunity to explore broadly and bring new insights to the domain. The clients are really eager to see what we come up with. In fact our clients, like true HCI practitioners. value our research as much as our final prototype if not more. In the same spirit, they’re being pretty hands-off about prescribing any solutions or narrowing our scope.

Research

Making instructions is hard. You could probably take our word for it, but we also did a lot of secondary research to confirm this. It’s all part of our Research Plan that we’ve solidified over the past couple of weeks.

We looked at simple domains like LEGO instructions. We also looked into the instructions that exist in complicated domains such as construction. Things don’t always scale well.

After our kickoff with the clients, we generated a ton of questions that vary in specificity. Some were as simple as, “What is being measured?” while others were more specific: “What is the process when there is a deviation in the execution of a WAD?” We spent some time clusering these into groups and labelling them. It was an exercise known as Affinity Clustering, which is all too famous here.

There’s no shortage of PostIts here

We’re dealing with a domain that is still exponentially more complicated than cars or bridges (it’s rocket science). Its hard to scale any good instruction methods up to the level of specificity and complexity required by NASA. Another constraint is that WADs are often used in environments where it’s unsafe to have wireless devices. For instance, engineers must rely on paper in a facility that has explosive hydrogen in it.

We’ve learned a lot about who our stakeholders are in general too. Technicians and engineers are the people who primarily interact with WADs at NASA. Quality control specialists use WADs too, in their case it’s to validate work procedure. However, there are many other stakeholder in the process of approving WADs and ensuring they’re up to par.

Project managers also have a vested interest in making sure WADs are quality, and making sure work stays on schedule when something goes wrong with these documents. Data scientists have their hands full keeping track of which WADs are created, and integrating that with documented cases of deviation from WADs.

When working with a government agency, theres obviously a limitation to what we can share to the public about our domain. In fact its sometimes challenging for us to get our hands on the documentation we want. We’ve immersed ourselves in research that relates to the general idea of writing good instructions, but we still have big blind spots when it comes to the specific challenges at NASA. We have several stakeholders at NASA we can talk to, and we are basically barraging them with questions about WADs in order to clarify this.

Whats next?

We need some context to understand how WADs are used and where. So how do designers get context? Well, we use Contextual Inquiry. Its a method derived from anthropology, and it’s all about exploring the way people work and interact. We’re going to a facility, and we’re following engineers and technicians around to see how these documents truly get used. Until we know that, it’s hard to know what we’re building.

So this weekend were flying to [REDACTED NASA FACILITY] to do some contextual inquiry until Wednesday. This will likely be our biggest opportunity to do research all semester, so we’re pretty laser focused on that next week.

We’re excited about what we find, and we look forward to sharing as much of it as we can with you. We’re also excited to get out of the snow for a couple of days.

Stay tuned,
Team C-137

--

--

Tait Wayland
Nasa Capstone 2018

UX Engineer. Member of team C-137, NASA Capstone at Carnegie Mellon