a gratitude-focused social media app


UI Design
User Interviews


Jasmine To (Team Lead)
Dylan Bagwell
Anngie Villegas
Bibilomo Sanni




February 2023 - April 2023
(8 weeks)

Project 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.


  1. Design an app that allows users to quickly capture and share grateful moments.
  2. Fufilling a gap of a social media platform without comparison culture.
  3. A tool that merges different gratitude methods in an accessible method.

Figjam Workspace Here︎︎︎


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.

Morii was created for an Interaction Design I class project at Kennesaw State University. I wanted to create a simple social media app similar to BeReal because of how trendy and well-loved that app is. When I came across a gratitude practice that told people to look for the best parts of their day and take a picture of it to share with their loved ones at the end of the day, I knew I wanted my app to incorporate this practice. Other students in my class were interested in my idea, which is how I became the team lead.


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 standard element in a business project process. The goal of a kickoff meeting is for teams to convene and become aligned with the stakeholders’ plans and goals for a product.

Since this project was prepared for an Interaction Design I class, it is essential to note that there were no real stakeholders. Subsequently, our team held a theoretical kickoff meeting. This meeting was held on FigJam, an online collaborative whiteboard, and completed by filling out a kickoff meeting template. The template consisted of a problem statement that stood in place of a problem a real-life company would have. A collection of questions on the template helped our team produce assumption statements about the app and its users. We completed this kickoff meeting template to imagine and imitate what a kickoff meeting with stakeholders in real-world settings might be like. We took on the role of stakeholders and defined our problem statement.

At the end of this meeting, our team concluded that executive stakeholders believe that existing gratitude apps fail to allow users to share their moments of gratitude quickly. Therefore, executive stakeholders want a social media app that centers on users capturing and quickly sharing exact moments of gratitude with loved ones

Holding Stakeholder Interviews

Stakeholder interviews are meetings between the design team and those interested in the design or project. Here, the design team would usually record, explain the project, and ask the stakeholders questions to gather relevant information. Stakeholder interviews allow the design team to gain insight into what they seek, leading the project to success.

As stated in the kickoff meeting section, this project is for a class, and we did not have any stakeholders present. Using the same kickoff meeting template, our design team used assumption statements to imagine what stakeholders would want.

Here are a few of our assumption statements: 

  1. Our product would be used whenever users feel moments of joy. They would capture their moment and reflect on it.
  2. Our app would improve the practice of gratitude by making it a quicker and easier process.
  3. The #1 value a user would want to take away from our product is finding joy in the mundane.
  4. Some additional benefits include helping people live in the moment, helping people look at life from a different perspective, and helping people improve their mental health.
  5. We assume our users want to share small joyful moments in their day. However, users might not care to post about their happy moments. They must care to post for our app to be successful.

After our team concluded this portion of the Research Phase, we transferred our focus to user research to see how our assumptions align with possible user goals.

Conducting User Interviews

Before getting into interviews, our team must consider what kind of users would use our app. The GDD user Research Phase recommends creating a persona hypothesis to help decide who our candidates are for interviewing.

We started our persona hypothesis by stating that we have one main type of user: people who want to use the app to capture moments to practice gratitude. Even though we believe we only have one type of user, this type may vary in two ways. We labeled these two sorts of people as gratitude-invisible and gratitude-intentional. Gratitude-invisible people want to use the app not necessarily to practice gratitude but to have fun and show their friends and family the good parts of their day. On the other hand, gratitude-intentional people are those who intentionally want to use the app to practice gratitude.
With these two kinds of hypothesized users, our team looked for interviewees who practice gratitude and those who don’t intentionally practice gratitude but may practice occasionally. With these interviewees, our team needs to observe to see whether the two variations of users exist.
Our team interviewed a total of 5 interviewees on Zoom. Team members either had the role of a moderator (guiding the interview) or facilitator (taking notes during the interview). I wanted my team members to all have experience moderating an interview, so I allowed each member to moderate the interviewee they invited.

During interviews, interviewees were asked about their experience with gratitude and social media since our app is a gratitude-related social media. Regarding gratitude, participants answered questions relating to how often they practice, their specific method, and the struggles they may encounter during practice. When discussing social media, they responded to questions regarding their thoughts on social media and how likely they are to fall into comparison culture.

After each interview, the design team came together to complete affinity mapping sessions. Affinity mapping allows designers to visualize meaningful relationships by simplifying the large amounts of information received from interviews. Affinity mapping aims to get insights from team members and organize those insights into themes or patterns.

Our team completed affinity mapping on FigJam due to many interviews being online. Each team member typed out their important takeaways onto sticky notes. After spending around ten minutes generating notes onto sticky notes, I would discuss each note while the other members reflected and discussed similar notes. Sticky notes with the same ideas get clustered together, which develops a common theme or pattern.

Common sticky note groupings that emerged:

  • How they view gratitude
  • Their methods of gratitude
  • Their views on sharing gratitude
  • The importance of photo documentation
  • Struggles they face while practicing gratitude
  • Their experience with gratitude-related apps

The affinity mapping results were examined later in the Modeling Phase to synthesize information into user models.

Modeling Phase

Steps Taken to Develop a Persona:
  • Identify behavior variables
  • Mapping interview subjects to behavior variables
  • Seeking patterns in behavior
  • Synthesize characteristics
  • Define goals
  • Creating persona narrative

Identifying Behavioral Variables

Looking at our observations from user research, we listed behavioral variables. Behavioral variables are noticeable behavior patterns relating to interviewees’ activities, attitudes, aptitudes, motivations, and skills. Our team identified 15 behavior variables by looking at our affinity maps to seek noticeable behavior patterns. I then guided my team to map each of our five interviewees to the 15 behavior variables on visual continuums. At this point, we made sure to focus more on the placement of each interviewee in relation to each other rather than the precise point of where they belong on the continuum.

Afterward, we looked for clusters to identify significant behavior patterns. Based on observations of where interviewees were placed in relation to each other, I advised my team that significant patterns are made up of 3 or more interviewees clustered together. We clustered this way because 3 is greater than half of all the people interviewed. Due to one cluster observed for each behavioral variable (except for “frequency of practicing”), we know we are working with one primary persona.

Here is the list of significant behavior patterns derived from mapping and clustering interviewees on the continuums:

  • Has few methods
  • Short gratitude sessions
  • Willing to share gratitude with close people
  • Likely to compare herself to others
  • Gratitude is important to her
  • Public with gratitude
  • More vocal with gratitude
  • Believes gratitude would improve her life
  • Vents in her gratitude session
  • High social media usage
  • Takes a lot of photos
  • More tangible documentation
  • Gratitude is easier during negative moments
  • Uses gratitude for self

Synthesizing Characteristics and Defining Goals

Now that a list of significant behavior patterns is created, the next step is synthesizing characteristics and defining goals. For synthesizing characteristics, Cooper suggests short notes describing each behavior. However, before synthesizing characteristics, we gave our primary persona a name to help us visualize our persona better while writing characteristics for each behavior. The name we gave our persona is Presley Parker. After coming up with a name, I walked my group members through the significant behavior patterns in the list we created. I made sure we described each behavior with observed behavior from user research to ensure we used concrete data to support our design decisions.

We defined four end goals and one life goal for our primary persona. Cooper states that end goals are the most important for personas and that each persona should have three to five end goals. End goals “represent the user’s motivation for performing the tasks associated with using a specific product” (Cooper et al., 77). We made the end goals by looking at our list of significant behavior patterns and their descriptions. On the other hand, life goals are aspirations for a person’s life. Life goals explain why someone uses a specific product to accomplish end goals. The end goals we have listed explain what our primary persona, Presley Parker, wants to do with the app we create. The life goal describes Presley’s life aspiration, which can be satisfied by using our app to reach her end goals.

Requirements Phase

Now that we have a persona, our team needs to define what kind of information and needs our persona requires to reach her goals. This is the Requirements Phase, where we “define what the product will do before [designing] how the product will do it” (Cooper et al., 107). Requirements are not features of an app. They are data and functional needs of personas. Defining the what of a design is crucial because it provides an objective design. If we were to jump to the Frameworks Phase without outlining our persona's needs, we would create an app based on our teams’ tastes and wants rather than what Presley Parker needs to fulfill her end and life goals.

Steps Taken to Establish Design Requirements

These steps were completed in an iterative process. There were moments while writing the context scenario where we had to add or remove some persona expectations or design requirements.

  • Create problem and vision statements
  • Brainstorm
  • Determine persona expectations
  • Create context scenario
  • Establish design requirements

Creating Problem and Vision Statements

To get started on the Requirements Phase, we defined our problem and vision statements to understand where our scenarios and requirements are heading. These statements give the whole team and stakeholders a clear product directive. Both statements explain the reasoning behind why we are designing our app. The problem statement is more business focused, while vision statements are more user-focused. Data from problem and vision statements both come from personas and research.

The next step is to brainstorm. As stated earlier, the Requirements Phase defines the persona needs to create an objective design. However, this step is where our team lets out all of our ideas on what our app should contain. Brainstorming helps eliminate our preconceptions about what our app should look like to keep us open-minded. Cooper suggests saving these brainstorming ideas to be considered later in the design process.

Persona Expectations and Context Scenario

Now that all of the preconceptions on our app are detached, we move on to defining the persona's expectations. Users have a mental model of how a product works. These expectations should match what we are designing. To ensure our design meets the mental model of our users, we created a list of persona expectations. This list is built from the desires, behaviors, attitudes, and experiences the persona may have while using our app.

Our team worked together to create our list of persona expectations by looking through our persona narrative and our affinity maps. Since the app does not exist at this point, we had to hypothesize the expectations based on our research. 

After completing the persona expectations, we move to the next step of building the context scenario. Context scenarios describe the story of personas interacting with a future product. They explain the “primary touch points [that the] persona has with the system” (Cooper et al., 113). It is necessary to cover the context scenario because outlining the overall view helps us identify the design requirements.

To construct the context scenario narrative, I reviewed our persona with my team. I explained Presley Parker’s end goals and life goal. I also went over the persona narrative we made. This way, my team knows how to start on the context scenario. We envisioned how Presley’s day looks from the beginning to the end of the day, specifically focusing on her interactions when using our app. While working through the context scenario, we noticed a persona expectation that did not make sense with how our persona would interact with the app and removed it.  This shows that design is not a linear process but an iterative one.

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

With the completion of the design requirements, we established what the product is and what it should do. We can now move onto the Frameworks Phase to discover how the product behaves and is structured. Before prototyping the little details of our app, we started with low-fidelity prototyping by wireframing. This is because the design framework is the “overall structure of the users’ experience” (Cooper et al., 119). During this phase, we’re focusing on the visual arrangement of elements on each screen, the behaviors of the details, and the workflow between screens. Wireframing sets the foundation of how our high-fidelity prototype will look like. Having an overall layout gives us the flexibility to see the big picture of our app before solidifying our prototype.
In the GDD Frameworks Phase, several steps are needed before getting to the actual wireframing. Form factor and input methods must be established, as well as the functional and data elements. Additionally, functional groups and hierarchy should be determined. Since these steps were touched on in the Requirements Phase, we skipped these steps and jumped into wireframing.

Key Path Scenarios and Validation Paths

In wireframing, we constructed key path scenarios and validation scenarios. The key path scenario is the persona's most frequently taken path when interacting with a product daily. While the context scenario is more goal-oriented, the key path scenario is more task-oriented. Once the key path scenario is completed, validation scenarios are added in. Validation scenarios are users' less frequently taken paths with the product, such as less often used tools.

To construct the key path scenario, I had our requirements list on hand to cross off whenever we completed a screen that fulfilled the requirement. We worked frame by frame and I constantly asked my team members to envision what screen users would see next after a specific frame. Once we had everything crossed off on our requirements list, we walked through our key path to make sure that we weren’t missing any screens that our persona would frequently see.

After completing the key path scenario, we created validation scenarios on the same wireframe, branching out from the key path scenario. Ultimately, these frames achieve the persona’s life and end goals.

View the full wireframe on FigJam.

Working in Figma

Using the wireframes as the foundation of our design, we designed our high-fidelity prototype in Figma following the 8-point grid design. Having a high-fidelity prototype allows us to have potential users test our app to see if they can understand the flow of our app.

We started by establishing our color and text styles. To do so, I suggested that my team members create the home screen together. Doing so allows us to apply the colors and text to see if we agree with the styles. I then asked my members which frames they would like to work on and split them among the team.

Refinement Phase

In the Refinement Phase, usability testing is carried out to see if the Morii prototype runs smoothly. Testing the prototype on potential users helps our team see if the key path and validation scenarios are coherent. Our team completed two usability tests, with one participant being someone we interviewed in the Research Phase. I moderated these tests while my team members took notes on their reactions and comments. I asked the participants to walk through the app and comment on what they liked, disliked, or found confusing.

Both participants found the interaction with Morii to be smooth. They expressed that the interface was straightforward to understand. One participant suggested we move the button in the profile creation frames up to make it more accessible.

Though both participants did not express any confusion, I noticed they paused on the frames where they had to choose their top Morii to post. I had to explain to them that after 8 pm, they would have three images uploaded, and they would have to choose one to post. To clear up this confusion, our team made the frames after 8 pm into the dark mode to clarify that the interactions on the app after 8 pm are different from the ones before 8 pm. For example, users cannot upload more images and voice memos once it’s 8 pm. They can only post and view their feed.

Additionally, we changed the home page before 8 pm to include three containers to represent three image uploads. During the usability testing, I reminded the participants that three pictures needed to be uploaded. To avoid confusion on how many photos need to be uploaded, the home screen now contains three containers to show that they need to upload three pictures in one day.


Morii was the first design project I designed with a team that brought an app idea to life. Though this was my first time creating a mobile app prototype with the method of Goal-Directed Design, the whole design process was made more manageable because we were simply designing with our persona's goals in mind. In the Research Phase, we learn about who our potential users are. In the Modeling Phase, we develop who our persona is. In the Requirements Phase, we establish our persona's goals. From there, we can create wireframes of our app in the Frameworks Phase with our persona's goals and needs. Finally, in the Refinement Phase, we test to see if our prototype continues to satisfy our persona's goals. Throughout the whole process, we kept our persona's goals in mind to help us think about how users will interact with our app and what they need to accomplish. This allows us to create a more intuitive and smooth experience, ultimately making our 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.

        Last updated: December 2023