Role
UX DesignerUX Researcher
Duration
8 weeksTools
FigmaFigJam
Discord
Skills
PrototypingUser Interviews
UI
OVERVIEW
Morii is a social media app focused on users practicing gratitude. This is done by limiting users to taking only three pictures of moments they wish to capture and revealing them later in the day for viewing. We designed this app for our Interaction Design class, where we were taught and followed the Goal-Directed Design (GDD) method.
A gratitude-focused social media app
Morii is a social media app focused on users practicing gratitude. This is done by limiting users to taking only three pictures of moments they wish to capture and revealing them later in the day for viewing. We designed this app for our Interaction Design class, where we were taught and followed the Goal-Directed Design (GDD) method.
Concept
Morii is the desire to capture a fleeting moment, to press pause during a life stuck on play. Morii is a social media app that focuses on the practice of gratitude. With this app, users will take three pictures every day. These pictures can be of small moments that made them happy, and they’ll be asked to explain through a short voice memo on what occurred during that moment to bring them joy. At the end of the day, they’ll receive a notification where they choose one of the three pictures to post. Once their post is uploaded, they can see and interact with their friends’ posts.
Method
Our team followed the Goal-Directed Design (GDD) process to create the Morii app. Alan Cooper founded GDD, and his methodology is explained in his book, About Face. The method of Goal-Directed Design is to offer design solutions that focus on achieving users’ goals. Designers must thoroughly understand user goals to create a successfully designed product.
Cooper’s methodology includes six phases: Research, Modeling, Requirements, Framework, and Support. However, GDD was adapted for the Interaction Design I class at Kennesaw State University to fit a 16-week course. Therefore, our team did not complete the Support Phase as we did not pass our prototype off for developers to code.
Research Phase
The GDD method is based primarily on qualitative research to search for behavior patterns. Research allows the whole team to understand the potential users of a product, the product domain, and what the company's stakeholders are asking for. Contextualizing these aspects ensures designers design products that fulfill user and business goals.
Steps Taken During the Research Phase:
- Completing the kickoff meeting
- Collecting literature reviews
- Completing competitive auditing
- Holding stakeholder interviews
- Conducting user interviews
Completing the Kickoff Meeting
A kickoff meeting is a typical part of a business project, aimed at aligning teams with stakeholders’ goals for a product.
In our Interaction Design I class, we didn’t have real stakeholders, so we held a theoretical kickoff meeting using FigJam, an online whiteboard. We filled out a template that included a mock problem statement and questions to help us create assumptions about our app and its users. This exercise allowed us to simulate a real-world kickoff meeting.
By the end of the meeting, we determined that executive stakeholders believe current gratitude apps don’t let users share their moments of gratitude quickly. They want a social media app focused on capturing and sharing those moments with loved ones.
In our Interaction Design I class, we didn’t have real stakeholders, so we held a theoretical kickoff meeting using FigJam, an online whiteboard. We filled out a template that included a mock problem statement and questions to help us create assumptions about our app and its users. This exercise allowed us to simulate a real-world kickoff meeting.
By the end of the meeting, we determined that executive stakeholders believe current gratitude apps don’t let users share their moments of gratitude quickly. They want a social media app focused on capturing and sharing those moments with loved ones.
Holding Stakeholder Interviews
Stakeholder interviews are meetings where the design team talks to people interested in the project to gather important information. These discussions help the team understand what stakeholders want, which is crucial for project success. Since this project is for a class and we didn’t have actual stakeholders, we used assumption statements to guess what they might want.
Here are some of our assumptions:
After this part of our research, we shifted our focus to user research to see if our assumptions matched users' actual goals.
Here are some of our assumptions:
- Users would engage with our product during joyful moments to capture and reflect on them.
- Our app would make practicing gratitude quicker and easier.
- Users would primarily want to find joy in everyday life.
- Additional benefits might include living in the moment, seeing life differently, and improving mental health.
- While we think users would want to share joyful moments, they might not feel inclined to post them, which is important for our app's success.
After this part of our research, we shifted our focus to user research to see if our assumptions matched users' actual goals.
Conducting User Interviews
Before our interviews, we need to identify the users of our app. The GDD user research phase suggests creating a persona hypothesis to determine our interview candidates.
We believe there is one main user type: people who want to use the app to capture moments for practicing gratitude. However, this user type can vary in two ways: "gratitude-invisible" users, who use the app for fun and to share their good moments, and "gratitude-intentional" users, who specifically want to practice gratitude.
With these two user types in mind, we sought interviewees who practice gratitude and those who don’t, but might do so occasionally. We wanted to see if these variations exist.
We interviewed five people via Zoom, with team members taking on roles as moderators or note-takers. I encouraged everyone to gain experience by moderating the interviews they arranged.
During the interviews, we asked participants about their gratitude practices and their thoughts on social media, as our app is a gratitude-focused social platform. We explored how often they practice gratitude, their methods, any challenges they face, and their views on social media and comparison culture.
After each interview, the design team held affinity mapping sessions. This process helps designers organize and visualize key insights from the interviews by grouping similar information. Our team used FigJam for this, as many interviews were online. Each member wrote their main takeaways on sticky notes. After about ten minutes, we discussed each note, looking for similar ideas. Sticky notes with related ideas were grouped together, forming themes or patterns.
Some common themes that emerged were:
The results were later analyzed in the Modeling Phase to create user models.
Some common themes that emerged were:
- How they view gratitude
- Their methods of expressing gratitude
- Their thoughts on sharing gratitude
- The importance of photo documentation
- Challenges in practicing gratitude
- Experiences with gratitude-related apps
The results were later analyzed in the Modeling Phase to create user models.
Modeling Phase
Steps Taken to Develop a Persona:
|
Identifying Behavioral Variables
Based on our user research, we identified behavioral variables, which are patterns related to the interviewees' actions, attitudes, skills, motivations, and abilities. Using affinity maps, our team found 15 key behavior variables. I then helped the team map each of our five interviewees to these variables on visual scales. We focused more on how they compared to each other rather than their exact position on the scale.
We then searched for clusters to spot important behavior patterns. I told my team that patterns are significant if 3 or more interviewees are grouped together, based on where they were placed in relation to each other. We chose 3 because it's more than half of the total interviewees. Since we found one cluster for each behavior (except "frequency of practicing"), we know we’re dealing with one main persona.
Synthesizing Characteristics and Defining Goals
After creating a list of key behavior patterns, the next step was to identify characteristics and set goals. To do this, we followed Cooper's advice by writing brief notes for each behavior. Before that, we named our primary persona "Presley Parker" to better visualize them while outlining their behaviors. I then walked my group through the behaviors, ensuring they were backed by data from user research.
We established four end goals and one life goal for Presley. According to Cooper, end goals are crucial because they reflect the user's motivation for using a product. Life goals represent broader aspirations. The end goals show what Presley wants to achieve with our app, while the life goal explains how the app helps Presley fulfill a larger life ambition.
Requirements Phase
In this phase, our team identifies the information and needs of our persona to help her achieve her goals. This step is about defining what the product will do, not how it will do it. Requirements focus on the data and functional needs of the persona, not specific app features. Clearly defining this ensures the design is based on the persona’s needs, not just our team’s preferences. Skipping this step could lead to designing an app that doesn’t align with what Presley Parker needs to reach her goals.
Steps to Establish Design Requirements:
This was done through an ongoing, repetitive process. While writing the context scenario, we sometimes had to adjust persona expectations or design requirements.
Steps to Establish Design Requirements:
This was done through an ongoing, repetitive process. While writing the context scenario, we sometimes had to adjust persona expectations or design requirements.
- Define problem and vision statements
- Brainstorm ideas
- Identify persona expectations
- Develop the context scenario
- Set design requirements
Creating Problem and Vision Statements
We start the Requirements Phase by defining problem and vision statements to guide our scenarios and requirements. These statements provide clear direction for the team and stakeholders. The problem statement focuses on the business side, while the vision statement is more about the users. Both are based on research and personas.
The next step is brainstorming. In the Requirements Phase, we define the user's needs to guide the design, but here, the team shares all ideas for what the app should include. Brainstorming helps us stay open-minded and avoid sticking to early assumptions. Cooper recommends saving these ideas for later in the design process.
Persona Expectations and Context Scenario
First, we define what our users expect from our app. Users have certain ideas about how a product should work, and our design needs to match those ideas. We created a list of these expectations based on users' desires, behaviors, attitudes, and experiences. We used our persona narratives and affinity maps to make this list, even though the app doesn't exist yet. This list is based on our research and predictions.
Next, we build a context scenario, which is a story about how personas will use the future app. It shows the main ways users will interact with the app and helps us identify design requirements. To create this, I discussed our persona, Presley Parker, with my team, including her goals and daily routine. We focused on how she would use the app throughout her day. During this process, we removed any expectations that didn’t fit well with her interactions with the app. This demonstrates that design is an iterative, not a linear, process.
Establishing Design Requirements
Using the context scenario we made, my team created our design requirements. To do so, we went through each sentence in our context scenario and asked ourselves if there was an action that helped fulfill our persona’s goals. If yes, we would write that action or context as a requirement in the following format provided by Cooper:
Call (action) a person (object) directly from an appointment (context). After we got all our requirements listed, we reordered them from the level of importance, with the most important being at the top.
Frameworks Phase
After defining what our product is and what it should do, we move to the Frameworks Phase. This phase helps us understand how the product behaves and is organized. We start with wireframing, which is a low-fidelity way to sketch out the basic layout of the app. This helps us plan the visual arrangement, details, and workflow before creating a detailed prototype. In this phase, we would normally decide on the form, input methods, and functional elements. Since we covered these in the Requirements Phase, we went straight to wireframing.
Key Path Scenarios and Validation Paths
In wireframing, we created two main types of scenarios: key path and validation scenarios.
- Key Path Scenario: This represents the most common route a user takes daily when interacting with the product. It's task-focused and helps us ensure that the primary user tasks are covered.
- Validation Scenarios: These involve less frequent paths or tools that users might use occasionally. They help check if all less common interactions are properly accounted for.
To build the key path scenario, we used a list of requirements, marking off each one as we completed it. We worked frame by frame, asking team members to imagine what users would see next. After verifying that all requirements were met and that no important screens were missing, we then added validation scenarios branching from the key path. This process ensures that both everyday and less common user goals are addressed.
Refinement Phase
| In the Refinement Phase, we tested the Morii prototype to see how well it worked. We ran two usability tests, including one with a participant we had interviewed earlier. I led the tests while my team took notes on the participants’ feedback. We asked them to use the app and share their thoughts on what they liked, disliked, or found confusing. Both participants found the app easy to use and understand. One suggested moving a button in the profile creation section to make it easier to find. Although they didn't seem confused, I noticed they hesitated when choosing their top Morii to post. I had to explain that after 8 pm, they would have three images uploaded and would need to choose one to post. To address this, we changed the app's appearance after 8 pm to dark mode, so users know that interactions change after that time. For example, they can no longer upload more images or voice memos after 8 pm; they can only post and view their feed. |
We updated the home page before 8 pm to show three containers for image uploads. During usability testing, I reminded participants that they needed to upload three pictures. To make it clear that three photos need to be uploaded each day, the home screen now displays three containers.
Conclusion
Morii was the first app design project I worked on with a team. We used Goal-Directed Design to create a mobile app prototype. This approach made the process easier by focusing on our persona's goals.
By focusing on our persona’s goals throughout, we created a smoother and more intuitive app experience, making users happier.
Lessons Learned:
- If we had more time, I would have interviewed people who were not fans of the app BeReal. Since our app is similar to BeReal, I would like to understand why certain people are against using that social media.
- I would like to have completed more usability testing with people unfamiliar with our app. One usability tester was one of our user research interviewees. The other tester had heard about our app. During our usability testing sessions, I made the mistake of walking them through the whole app and explaining what they saw. I should have done the opposite and made them explain what they thought was happening.
- In the Frameworks Phase, when working in Figma on our high-fidelity prototype, our team learned how iterative design was. We added many more frames than we had drawn up in wireframing.