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.

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.

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:

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.

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

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.

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.

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.

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.

Conclusion

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.