The Empathy of Menstrual Cycles — a UX case study
The Challenge:
Communication is the key to any successful and growing relationship and it is easier when both parties understand how each other feels. Portraying these feelings is easy for some and difficult for others, especially when it has to do with your period.
Everyone is unique, especially regarding their body’s functions. This uniqueness sometimes makes it difficult to express how we feel physically or emotionally. Even if someone is comfortable talking about their body, it does not mean they want to talk about it every day.
My team and I decided to explore the different ways to document and communicate their feelings and symptoms related to menstruation.
The Team:
The Process:
I have chosen to generally organize this case study to help guide the reader through our experience; however, the true process was far from this linear.
- Empathize — to gain an empathetic understanding of the problem that we are trying to solve.
- Define — to define the core problems using the information we gathered.
- Ideate — to design solutions to the discovered problems being faced.
- Prototype — to identify the best possible solutions to all the problems discovered through iteration and testing.
- Test — to evaluate the products ability to meet the needs of the end-user easily and efficiently.
Audience:
I had to understand who would be using this application. The obvious challenge here is that our users would not strictly be male/female relationships. There are also those that identify as male, while still experiencing menstrual symptoms. There could even be a situation where roommates wanted to track each other. I needed to refer to the different users while being as inclusive as possible.
I will reference the following acronym throughout the rest of the case study. This term helped us start the conversation internally and direct how we framed our interview and survey questions.
Assumptions:
As a team, we discussed our assumptions around how PEMO’s communicate about their cycle with their partners. Below are some of those assumptions.
- PEMO’s are open about discussing with their long-time partners.
- PEMO’s don't want to use their symptoms as an excuse.
- Non-PEMOs can only give superficial support.
- Non-PEMOs are not interested in learning how their partner’s body changes.
User Research:
I started determining survey and interview questions that would get to the core of what we were trying to explore. I developed three interview questions that were open-ended to just begin the conversation about the couple's cycle. I relied heavily on follow-up questions and reading the room in order to really find the stories people were willing to share.
“We have a very open communication. I like telling him how I’m feeling and he caters to my needs.”
“We are open about everything, and the fact that he understands what I am going throughout helps both of us.”
“I feel like it should be an open conversation”.
“To express a health concern or frustration with symptoms. Also to explain why I wasn’t interested (or couldn’t be interested) in having sex. It is frustrating to have to say you’re on your period, but it causes other issues when your partner doesn’t know.”
With the survey and interview questions, we wanted to have an all-inclusive tone to not isolate any specific types of relationships. Also, many apps currently on the market are overtly feminine and over-the-top with themes of pink and flowers. I wanted to learn from the feedback that the current market has received, and create an app that both PEMO and non-PEMO’s would feel confident and comfortable using.
Crafting the survey to be sensitive, professional and curious was a challenge all to itself, but I knew I would have to start exercising those skills to be able to move forward in this project in a meaningful way. The sooner I could empathize with the potential users, the sooner I could collect meaningful data.
After posting in the subreddit r/TrollXChromosomes for some constructive criticism, I discovered that Clue (an app currently on the market) has a connection feature. However, after doing a bit of exploratory research, we discovered it was missing the in-depth, personal communication method that we envisioned for our app. In Clue, the communication between PEMO and non-PEMO is limited to knowing approximately when the cycle begins and ends. This encouraged us to look at a more empathetic way of connecting with others in the app.
Persona:
Using the data gathered from our in-person interviews, and our online survey, I created two separate user personas. These user personas were meant to be a personification of the average data and responses we collected.
Both the PEMO and non-PEMO personas would have specific goals that I would need to define, and this allowed me to use those goals to gauge our success.
Alex’s Short Term Goals:
- Track my cycle to plan when my body changes.
- Effectively communicate with my partner so that they better understand my body and feelings.
- Manage my emotional changes and how they affect my day-to-day life.
Lyle’s Short Term Goals:
- To cater to his partner’s need.
- To empathize with his partner’s feelings.
- To be informed in a casual way about his partner’s cycle.
User Story Mapping/Wireframing:
I started developing our user story map and our wireframes in tandem. This allowed me to focus our efforts on one narrative at a time, then design the flow in the wireframes accordingly. We initially ran into little issues, but as we started to get into the nuances of how the PEMO would share (and control) their cycle information with their partner, we started to face many challenges. I reached out to different users to direct our initial choices, however, I knew at the time that I would need to clarify the experience in the future.
While developing the wireframes, we ran into many challenges regarding how the user documented their symptoms and how those document’s symptoms translated into shared content. We wanted the app to not only be a medium someone could use to talk to their doctor, but also an instrument to communicate with their partner. We knew we needed to make it clear when content was being shared so that the person sharing the information would be confident in documenting without worrying about oversharing.
Wireframing:
After finishing the user story mapping, I started to combine all of our wireframes into an initial design. I knew that I would receive the best feedback from completed flows, so I pushed to put the first iteration in front of user testers.
After doing some user testing, we discovered one of the improvements we needed to make was to our sharing flow. The issue was that it was unclear what was being shared, or how to share it and clarify how a user would not only share their cycle but view another cycle. In the first version (below), we initially thought it would make sense to use the share screen as some sort of queue, where they would then be selected for sharing. However, this caused confusion regarding where the content was coming from. I redesigned the share experience (current version, below) to view what you have chosen to be shared instead of a second layer of confirmation.
Being able to switch from your data to view your partner's data was a challenge throughout the whole design. I tested the idea of swiping to switch profiles, but it wasn’t clear to the users we tested with. I thought about adding arrows on the left and right of the screen to imply a swipe but did not like how much presence they had on the screen. I found success through the users with the idea of a dropdown menu with a caret housed in the header.
User testing was not the only learning mechanism during this project. I also benefited from my collaboration with the iOS developers early. They recommended that within our set amount of time, I should look at an alternate calendar layout to accommodate the skill set of our team. This shift in time use also helped them use more time to develop the navigation arc on the home page.
Another discovery that came from usability testing was that the data branch of the app was redundant. Our initial intention for the data branch was so the user could reference it when talking to their healthcare provider. It would organize the documented information by cycle, and show you what days there were documented symptoms. However, when multiple users came to that screen, they questioned what they would use it for if they had the calendar.
Both tracked symptoms, and the days of the month and cycle. The small difference between the Data Tab and Calendar Tab was that the Data Tab organized the cycle days in a list, whereas the calendar was organized by month. This difference was not important enough to develop the whole branch in our given time frame. This led to us removing the data tab from the app for now and moving calendar access to the bottom navigation.
Prototyping this product was extremely important throughout our project schedule. I knew that we needed to get a mid-fidelity prototype in front of users would give us useful feedback. Once we were confident of our mid-fidelity designs, we began to high fidelity mock-ups.
We decided on “Know.” for the title of the app. This referenced the tracking and “knowing” about your body while sharing that experience others. I also wanted to imply the use of the app subtly, hence the red period.
I knew that many apps on the market received criticism for being overly feminine, and I knew that if we wanted many different types of people to feel confident in using this app, we had to gravitate toward a neutral modern look. The color scheme is a two-stage gradient change from gray-blue to mint green.
I also decided to designate colors to the different types of categories of information the user would be documenting. These were more pastel colors to contrast with the primary color scheme of the app.
As mentioned throughout this case study, I understand the importance of testing early and often. I owe many of improvements made to the generous users that gave critical feedback.
The project is currently on the App store as version 1.0, and currently being updated and improved.
Next Steps:
Continuing this project, I would revisit our data tab to clarify its use to set it apart from the calendar. I also think that the share tab could be improved to be more personalized to the PEMO’s message.
Through our research, we discovered that many people were open to receiving notifications from their partners. From that, we thought it would be beneficial for the non-PEMO to be able to see the scale of the severity of the symptoms. This evolved into a rating system that would be implemented in the symptoms documentation page. The rating system started as a slider that would be under the selected symptom, and after selection, there would be a number the would appear on the symptom.
During the user testing, we found that the number was too similar to the iOS notification graphics. This led to confusion as to what the number meant. We began to redesign the rating system with a gauge around the exterior, that would fill in as the rating increased. We looked at other options, however, we moved the idea of rating symptoms to a stretch goal, as it was quickly becoming a much larger scope than initially expected. This is one of many things I would like to continue with more time.
Conclusion:
This project was an incredible challenge for me. I had to develop a whole different vocabulary to be sensitive and sincere about the subject matter of the app. I also had to show humility quite often because I did not know about many of the topics that came up. I appreciate that this app pushed me outside of my comfort zone and I had to adapt to the relevant information and the project schedule.
This app is only scratching the surface of what it could do, but improving it will be no easy task. With more time, this could be developed into a platform for people to automatically share information about themselves and bring greater awareness to the complex thing we call the human body.
