Sent, Received, Delivered (I’m Yours)
Sprint 8: Chat Prototypes and the Mental Model for Deep Space Communication
“It’s human nature to stretch, to go, to see, to understand.” — Michael Collins, Apollo 11
We all have mental models for how we might expect communication to be organized. Maybe it’s like instant messaging or texting on your phone where every message falls into one long strand of conversation between you and the person you’re communicating with. Maybe it’s more like email where everything is grouped by the topic of conversation.
In short, this two-week sprint has been all about transitioning from connecting the chat with other components of Playbook (calendars, procedures, tasks, crew status, etc.) to focusing specifically on communication itself. At the core of our work has been the need to understand the user’s mental model for asynchronous communication. With this knowledge in our toolset, we plan to adapt our designs for a future where astronauts and MCC communicate with long periods of uncertainty about when the next message might come and what it might be about.
Diving Deeper into Communication 🤿
With the many ideas we had in Sprint 7 surrounding the overall layout of a future communication tool (such as a reimagined Playbook and Mission Log), we learned quite a bit about the context that crew members and MCC need when they are composing a message and just how much information comes from other aspects of Playbook. While we loved the ideas and enjoyed exploring future concepts for Playbook, we also knew that we needed to dive deeper into the chat itself given our short timeframe this summer.
With 5 team members and a combined 200 hours a week for the team, we rehashed our division of work and our overall direction, which was focused on a key question and piece of feedback “What question or questions do you need to answer now that will dictate the rest of the project?” With many unknowns still remaining in the actual chat or communication interface and interactions, we knew we needed to hone in on the chat itself and hammer out features that would not only deal with basic communication, but also the nuances of delayed communication.
Week 1: Starting the Chat Re-Design 📩
First up was handling some of the unknowns in time-delayed communication. Imagine a quick scenario, where you are on Mars directing an EVA with fellow astronauts who are out collecting rock samples. You are in communication with MCC, but it’s delayed 40 minutes so real-time pivots and changes based on communication from MCC are sometimes out of sync. You decide to send one of your crew members to a new area for sampling, off-plan from the EVA. After sending your updates to MCC, you received a message from MCC asking you to send the crew member you just rerouted, to an old site for more sampling.
Obviously, this type of communication is confusing, and assessing whether to pay attention and listen to the incoming request can be highly taxing on you. How do you know what information MCC had when they sent that request? Are they basing it off of where you were 20, 40 minutes ago? If you send a request for clarification, it will take 40 minutes to get a response at a minimum — do you know where you will be in the EVA plan at that time? Will the information be useful and pertinent when it comes back to you (in the future)?
This is something we call “time-math” (described a bit in our previous medium post). In short, it’s a cognitive-load inducing problem that will occur frequently in future missions to Mars. We’ve brainstormed and sketched many ideas to address this problem, ranging from simple indicators of timings of messages, relational or spatial connections for messages, as well as “modes” that enable a user to “troubleshoot” these conflicting types of messages.
During the first week of Sprint 7, we decided to explore how our users might utilize message timing details, message status, and other chat features to understand and troubleshoot a conflicting conversation. With this in mind, we created a prototype to test the effectiveness of our ideas and understand their impacts on the user experience.
Message Details
A core feature of any chat interface — users need to know when a message was sent and received — this is especially important when time delay is involved and the sent and received times are not the same (as they might be in synchronous communication).
Message Status
Clearly and visually distinguishing the current status of a message, as well as showing some indication of when a status may change (such as an ETA of delivery) may help users spend less mental resources tracking their message and figuring out when they might hear back next.
As Sent Mode
Beyond the details and status of a message, we also prototyped features that would aid in a user’s attempts to understand the context of the other party’s messages and to help with the essential question of “What did they know when they sent that message?”
One feature (“As-sent” mode) reorganizes the order of the messages according to the time that messages were sent by the other party. In a typical chat, messages are ordered by the time you receive them, but with a 20 minute delay that could make the conversation not make sense and look out of order. The idea with “as-sent” mode was to find a common perspective and a common timeline for both crew and MCC so that they can easily troubleshoot a conflicting conversation.
What We Learned from Our First Prototypes
The beauty of lower fidelity prototyping is that we can create, test, and drive our designs forward in rapid fashion. And we did exactly that in our first 1-week sprint with the chat interface. We learned a LOT in a short period of time, and we have a long list of changes to make, but more importantly we realized that some of our assumptions might not be entirely accurate and also that some of our ideas just weren’t what we needed them to be.
Our first big takeaway was that changing perspectives when looking at a conversation is actually really hard and mentally taxing! It’s not easy for a user to simply look at a conversation and then re-piece it together from the other party’s point of view. That said, reorganizing the messages in the order they were sent was a bit of a nightmare for users to wrap their heads around. It’s not what they’re used to but it’s also difficult to really grasp the scenario when the messages change order, and you have to trace where they went yourself. Out of this, we realized that we should aim to find a common perspective or timeline for all of our users to operate on and not ask them to change views in order to troubleshoot a conflicting conversation. As an alternative to “as-sent” mode, we piloted a message tracing feature that would link a particular message to a point in time in the conversation, so that users can quickly tell what information was relevant when that message was sent without changing the order that the messages show up in the UI.
Week 2: How Should an Asynchronous Conversation Be Organized? 📁
The second big takeaway from our first week is that a text message style layout might not even be the correct mental model for how users expect an asynchronous conversation to be organized. The assumption that a chronological ordering of messages is appropriate for our scenario was something that we had unknowingly incorporated in our designs during week 1! We needed to go back to the drawing board for week 2 and really understand if there is a better mental model. We wrote down the following goal and hypothesis to provide direction for week 2.
Goal: Assess the mental model of asynchronous communications that our users have.
Hypothesis: If asynchronous conversations are organized by topic, then users will be able to clearly understand the context of the situation through conversations, so users’ situational awareness will be improved.
The topic-based organizational structure we wanted to explore in the second week of this sprint was based on an accumulation of papers and speed dating findings that pointed to how topic threads are useful in asynchronous communication. We wanted to understand how users want to visualize these topics, so we designed an A/B test to assess how an email-like interface compared with a chat-like interface for communication.
Back to the Drawing Board
But… not all things go to plan. During our capstone class, we were very fortunate to have industry professionals take a look at our projects and help us synthesize our usability test data. When we brought up our findings from last week and the confusion our participants faced, we realized that we should go back to sketching to fully explore the mental model of asynchronous communication at a higher level.
We went back to the drawing board and came up with tons of sketches for both time and topic-based message organization. However, we were still stumped as to how to move forward. Which sketches were closer to our users’ mental model of asynchronous communication? Were there some ways people organize messages that we hadn’t even considered yet? How do people even make sense of messages that appear out of order? So. Many. Questions.
Card Sorting
To try and answer these questions, we pivoted away from our original A/B testing plan for the week. We went on to design a card sorting exercise where participants organized messages in whatever way made sense to them.
One key part of this activity was that our participants actually had to understand the content of the messages. In previous sessions, we filled our prototypes with what we imagined highly technical conversations might look like during a time-delayed EVA, which made it difficult for non-SMEs to understand what was going on in the messages. With card sorting, we needed to make sure that the conversation was easy to understand in case the content of the messages impacted how people organized the cards. So, we created The Party Story:
You and your family are hosting a graduation party for your sibling, your friends are joining along for the fun, and you need to pick up some supplies at a store before the party. The store, unfortunately, is in an area with almost no cell-service. You are in charge of the group of friends to go pick up the items for the party. With the lack of strong cell-service, messages from you and your friends take 20 minutes to be delivered to your mom and vice versa. Additionally, you are also in another conversation with the same people about a post-graduation road trip at the same time.
Our card sorting sessions gave us the sense that this story was definitely much more immersive, relatable, and easier to understand than the previous one. Overall, we found some interesting results from this exercise after testing with six participants.
Initial Takeaways
- It’s harder than it looks: most people struggled to organize the messages, especially when messages came in out of order and disrupted the flow of the conversation. One participant was unperturbed and mentioned that not everything can be conveyed visually. Sometimes, it might be necessary to read timestamps to get the full picture.
- Threads & subthreads: All participants grouped the messages into threads based on topic. Some people subdivided the threads into subthreads to keep things as organized as possible with the time delay. We also learned that some people weren’t organizing the messages by topic for organizations’ sake, they were trying to understand what actions they should take next to prepare for the party.
- Sent, received, delivered: The timestamps we provided next to the messages were used differently across many participants. Some people used the message sent time to order the messages chronologically, some did the same with received time. Some were confused as to who the timestamps were relative to. Some ignored the timestamps entirely and ordered the messages based on content alone (such as putting an answer directly underneath the question).
Next Sprint Coming Up 🏃♀️
Now that we have more information on how people visualize asynchronous messages, we plan to spend a majority of our time in the next sprint updating our old designs with our new findings. We also want to create a future roadmap for Playbook that illustrates our far-reaching ideas for space communication, and how NASA might get there. Lastly, we’re currently finishing up our protocol for our simulated mission/ORT and creating a functional chat prototype (code included!) so that we can run some sessions over the next few weeks. We’re excited to see where Sprint 9 will take us!
Chronos Communication
These 1-week GV sprints can get a little stressful, so to keep things light, we’ve found these hilarious photoshopped images with the iconic astronaut pose and we’re now using them as our Zoom profile pictures in team meetings:
CMU has also eased some restrictions surrounding COVID and on-campus access, and we’ve FINALLY been able to use our project room, which has been home to NASA teams for some number of years now. Since the team is working both remotely and in-person for long periods of the day, we’ve scooped up a LOT of conference tools like Facebook’s Portal to make it a little easier in this hybrid work world. We think we’ll be able to give a full report on the Portal’s usability by the end of the summer 😂
Signing off for now,
Chronos
Chronos Acronym Dictionary
AI: Artificial Intelligence
ARC: Ames Research Center
BASALT: One of NASA’s analog mission project to design and develop elements of future missions that could send humans to conduct science and exploration on Mars
CAPCOM: Capsule Communicator
CCTV: Closed Circuit Television
CDMS: Command & Data Management Systems Officer
CDR: Commander
CDS: Central Data System
DCS: Display & Control Monitor
ESA: European Space Agency
EVA: Extra-Vehicular Activity
F/C: Flight Controller
FD: Flight Director
HERA: Human Exploration Research Analog
IMF: In Flight Maintenance
INCO: Instrumentation & Communications Officer
IVA: Intra-Vehicular Activity
JSC: Lyndon B. Johnson Space Center
KSC: John F. Kennedy Space Center
MCC: Mission Control Center
MD: Mission Director
MS: Mission Specialist
MSCI: Mission Scientist
NEEMO: NASA Extreme Environment Mission Operation
SA: Situational Awareness
SME: Subject Matter Experts
Opinions expressed are solely our own and do not represent the views or opinions of The National Aeronautics and Space Administration (NASA)
