Hooty Hoo is a mobile app that aims to give Kennesaw State University (KSU) students an easier, more accessible way to connect with their peers and get more involved in campus life. It matches students on the basis of factors such as major, shared interests and hobbies, and one's interest in networking and peer mentoring. Students can talk to those they've connected with via in-app messaging. The app also features a campus event search, offering students another avenue for peer connection.
This app was created as part of a class project in KSU's Interaction Design I course using Alan Cooper's Goal-Directed Design methodology. In the rest of this process page, I will be going over how we navigated each phase of this methodology when creating Hooty Hoo.
Team Leader, UX Researcher, UI Designer, Prototyper
Figma, FigJam, Microsoft Teams
Arthy Natarajan, Mako Suga, J'Mya Cutter, Kiro Kilinski, and Lauren Madison
9 weeks (Feb - Apr 2024)
Goal-Directed Design (GDD) is a methodology created by Alan Cooper that places the needs of the user front and center throughout every phase of the design process. Following this methodology in the development of Hooty Hoo helped ensure we made design decisions that were user-centric and not self-referential.
The Research phase essentially entails collecting qualitative data for a product in regard to its users. Research served as the foundation for what Hooty Hoo was going to become. In this phase, my team and I set out to hone in on what exactly our app will need to accomplish. To do this, we needed to acquire a better understanding of our users and domain.
Kickoff meetings are a way for designers to gain a better understanding of what stakeholders expect a product to be and to learn more about their vision. Seeing as this was a class project, we did not have any actual stakeholders. For this reason, we instead completed a kickoff meeting worksheet and answered the posed questions in which my team and I assumed the role of stakeholders.
Our key assumption statements were as follows:
Literature reviews are done to ensure that designers have a solid foundational understanding of the product domain. For our project, we reviewed 5 articles pertaining to loneliness in college and the benefits of networking and peer mentoring to better understand how Hooty Hoo could potentially fit into the lives of KSU students.
From our literature review, we found the following:
Competitive audits are used to analyze competitor products within the same domain. We analyzed Bumble, GroupMe, and the KSU subreddit on Reddit. While doing this, we were particularly searching for existing gaps that Hooty Hoo could fill.
Some of the gaps we found were as follows:
Stakeholder interviews serve as a means for designers to obtain more insight from those in authority. As aforementioned, we did not have any actual stakeholders since this was a class project. Thus, we did not conduct any stakeholder interviews. However, the kickoff meeting worksheet functioned as a way for us to take on the role of stakeholders ourselves. In doing this, we got a better sense of how stakeholders may go about considering business needs as the worksheet contained questions regarding hypothetical revenue and competition.
Conducting user interviews is by far one of the most crucial parts of the design process as users are the people who will actually be utilizing the product. Thus, we knew it was vital that we gain a sound grasp of their needs in order to design Hooty Hoo in a user-centric manner.
Due to time constraints, we were only able to interview 5 people. All of our interviewees were KSU students as they would be the potential users of Hooty Hoo. We did a mix of face-to-face and virtual interviews, with the virtual ones being conducted through Microsoft Teams. I led and conducted 2 of the interviews and focused on note-taking and asking follow-up and clarifying questions for the others. Questions the interviewees were asked mainly centered around how they usually go about making friends and their experiences connecting with their peers at KSU.
After completing each interview, my team and I would do an affinity mapping exercise in FigJam. Affinity mapping refers to the process of gathering qualitative data from your users and then categorizing it. We went about doing this by having every team member create sticky notes for insights they collected during each interview. Following this, we analytically looked at everyone's insights to see if we could identify any correlations among them. When such correlations were found, we categorized them together as a group.
Here are some key insights we gained from this process:
Using everything we learned from our user interviews and the resulting affinity mapping exercises, our next mission was to craft Hooty Hoo's primary persona in the Modeling phase.
The Modeling phase involves synthesizing information discovered during the Research phase to find patterns, ascertain user goals, and craft personas, which are user archetypes comprised of distinct behavioral patterns and goals.
Drawing on our findings from our research and interviews, my team and I transitioned into figuring out what Hooty Hoo's primary persona would look like. We created 15 continuums, each based on a behavioral variable identified from our user interview data, and placed each interviewee on each of the 15 continuums based on information derived from their respective interviews. Following this, we analyzed the continuums to see if any behavioral patterns were apparent, and we found that 14 out of the 15 continuums each had one discernable cluster. Thus, we were able to see one distinct user archetype forming--our primary persona.
Using these identified behavioral patterns as a blueprint, we synthesized characteristics and defined 3 end goals and 1 life goal for our primary persona, and then jumped into crafting a persona narrative.
Meet Levi Chandler, a freshman at KSU in his second semester who wants to connect with his peers beyond just the typical class GroupMe exchanges.
The Requirements phase is all about fleshing out what needs to be in a product to support personas in accomplishing their goals.
To begin this phase, we solidified our problem and vision statements and brainstormed what Hooty Hoo may potentially look like, whether that be in terms of its literal look, features, functionality, or quite literally anything else pertaining to the app. We then moved into determining data and functional needs for our primary persona, Levi, by thinking from his standpoint and trying to determine what he would want and expect from an app like Hooty Hoo.
Using the above as a basis, we got to work crafting a context scenario to better understand how Levi might use and interact with Hooty Hoo in his day-to-day life to achieve his goals. From this context scenario, we extracted a requirements list, in which each requirement follows the structure of an action the user can perform on an object and in what context. An example of a requirement we had was being able to message someone (action) via direct messaging (object) after matching with them (context). Following this, we arranged the list by highest to lowest importance, and this revised requirements list is what served as the foundation for wireframing Hooty Hoo.
The Frameworks phase consists of formulating low-fidelity wireframes based on the requirements derived from the previous phase and then translating them into a high-fidelity prototype.
In our wireframing process, my team and I considered our requirements list and how Levi navigated Hooty Hoo in the context scenario. From this, we created a key path scenario and validation scenarios. A key path scenario refers to the path the user will frequently tend to take in the app, and validation scenarios refer to the paths the user won't take as frequently, but are still needed within the app. For example, screens such as the Home, Match, Events, and Hotspots pages fell under our key path scenario while screens such as the Settings and FAQ pages fell under our validation scenarios.
 (2).png)
Before moving into crafting the high-fidelity prototype, I made the decision to follow KSU's style guide for Hooty Hoo's color palette and typography because I wanted the app to feel like it could actually be something KSU created for its students and we created styles in accordance to this. As we transitioned into prototyping, there were many things that changed from our wireframing, the biggest example of this being the removal of the Hotspots page. The concept of the Hotspots page was to show users where other KSU students are hanging out on campus. In concept, the page seemed like a good idea, but after further discussion, we realized that the page would not be as useful in actuality since most students would always be hanging out in the same spots including but not limited to the Carmichael Student Center, The Commons, and the library. Thus, we nixed the page altogether.
As team leader, I delegated tasks by assigning everyone certain parts of the prototype to work on. I personally worked on designing all the pages associated with the sign up/login process and oversaw the creation of all the other pages, stepping in to make any necessary edits to ensure our app had a cohesive feel. I made sure the overall aesthetic of the app was consistent, ensuring correct color and text styles were being used, and checking if elements were aligned properly and evenly spaced out.
The Refinement phase is where a prototype is revised, fine-tuned, and polished, with a focus on feedback garnered from usability testing.
After getting our Hooty Hoo prototype to a near-complete state, my team and I ran two usability tests on it, both of which I led and conducted. Participants were asked to perform tasks such as sending a Hoot to a match, viewing received Hoots, using the filter in the Events page to select a particular campus, and other tasks that we believed a user might typically perform while using Hooty Hoo. We requested the participants to think out loud as they performed each task to gain a better understanding of the thought process that would go into navigating Hooty Hoo.
The feedback we received and how we went about fixing the issues to improve our app's user experience are as follows:
Overall, I enjoyed working on Hooty Hoo, and I believe this project was an insightful learning experience for me as a researcher, designer, and team leader. Because this was my first time doing a UX case study and moreover being the team leader for it, my initial organization for each phase was lacking and it took me a second to gain my footing each time because not only was I learning about the phases of Goal-Directed Design as we progressed through the project, but also how to be a leader, which was something I've always struggled with. However, after this project, I feel that my leadership skills have gotten more developed as I am now aware of my strengths and areas in need of improvement.
If I were given another chance to redo this project, I would definitely practice using Figma before diving into prototyping. After we got to the prototyping, I had a slightly difficult time guiding my team since I myself was relatively new to Figma and still had a lot to learn about it.
Another thing I would do is make sure to interview enough people within our pool of potential users. Due to only being able to interview 5 people for this project, we unintentionally ended up interviewing only upperclassmen when interviewing freshmen or sophomores would have given us more perspective from students new to KSU, who arguably fit our primary target audience much better.