OwlsNest was created to help connect people on a college campus to the things that they want: events; whether that be posting events or finding them. Club leaders will be able to share their events without hassle, while at the same time, students can filter through events to find exactly what meets their needs and interests. OwlsNest will revive event attendance by appealing to how students generally choose to meet people today - through their phones.
Team Lead, Moderator, Researcher, UX Design
Miro, Figma, Google Docs, Discord, and Teams
February - April (8 Weeks)
Team Lead
Visual Designer
UX Designer
UX Writer
For this project, me and my team followed the design process Goal-Directed Design, which was created by Alan Cooper. This process helps designers by giving them a series of phases to walk through the creation of their product that prioritizes the goals of the user over everything else. There are six main phases of this process: Research, Modeling, Requirements, Framework, Refinement, and Support.
These steps helped our team to stay focused on the task at hand, making sure that we gathered information that would directly align with what our users would want from our application. We took this information and used it to define key behaviors that a standard user of the app would go through, which in turn affected the paths of our wireframe, and eventually the final prototype.
When creating the idea for OwlsNest, I wanted to provide a better experience for college students to find and participate in events on campus. Previously, advertisement was not strongly pushed and I was unaware of many things going on, often finding out about them days after they had ended. OwlsNest would come in to take the place of event advertisement, creating a modern, easy experience for both on-campus residents and commuter students alike to help them grow and explore a social life on their college campus.
Our first step in this process is the Research Phase. For this, our team began with a Kickoff meeting, where the four of us met together virtually to simulate what would happen at a true corporate kickoff meeting. We did our best to explore the ideas of our application and it gave us the basis that we needed to move forward. To display our research, my team composed a formal research report that included the ideas from our Kickoff Meeting, a Literary Review, Competitive Audit, a simulated Stakeholder Interview, and our User Interviews.
As a team of four in a class project, we were unable to partake in a true kickoff meeting. To accommodate for this, my team attempted to simulate the setting as best we could. The four of us met together virtually to simulate what would happen at a true corporate Kickoff meeting, following the general list of questions that Alan Cooper provided in About Face (37). We did our best to explore the ideas of our application, what we wanted to achieve, and the research areas that we wanted to look into that would give us a better understanding of the domain we were working in.
For the Literature Review. For this, one of the team members found various sources that discussed the areas in and around our domain and problem space. We took a deeper look at social media and how it effects the daily life of students. We also researched key ideas such as how a students college life is influenced by their social experiences. By looking into related topics, we helped to further our knowledge on the subject and provide us with factual evidence that we would carry with us into the stakeholder and user interviews and the rest of the design process.
I conducted the Competitive Audit by taking a closer look at related applications that have similar functionality to the app that we are designing. The purpose of this audit was to find both pros and cons of the current state of these applications, and use them to better inform how our application should work.I examined five different applications that included a range of the aspects that we were trying to include within our project. All of them were able to provide the team with various tips that we would later be able to compile into our wireframe and prototype.
A web based site for Kennesaw's events and clubs. It was confusing for users to navigate, and difficult for club leaders to establish events.
A web based site for Kennesaw's events and clubs. It was confusing for users to navigate, and difficult for club leaders to establish events.
An easy way to connect with friends and create events. Largely social based, but do not cater directly towards the needs of a college student.
An easy way to connect with friends and create events. Largely social based, but do not cater directly towards the needs of a college student.
Largely, it is a social platform for gamers, that has only recently moved into event planning. However, it is solely community driven.
In order for our team to create an app that was useful and intuitive, we interviewed multiple subjects that currently have affiliation with Kennesaw State University, including Bachelor's students, a Master's student, and a professor. By analyzing the subjects' attitude towards social events, digital event management, Kennesaw State University's current advertising technique, among other aspects, we began to understand the core problems that students and faculty faced in their current situation, as well as what they would like to see in a new and improved application. These interviews provided us ample information to then create user personas.
By interviewing current KSU students and faculty, we were able to test our suspicions, assumptions, and research on potential users to be sure that their mental model of our app met the mental model of the design team.
Alan Cooper defines a stakeholder as "anyone with authority and/or responsibility for the product being designed” (39), however in this project there were no official Stakeholders. This project was conducted for an Interaction Design 1 class, and thus the experience was simulated through a series of questions that my design team worked through. The main goal of this was to understand the preliminary vision for the product with these interviews and question it further. So, the design team began to brainstorm ideas and think like a stakeholder to try and discover what their goals for the product would be.
From this experience, our team was forced to think about the project through a business-minded approach. We explored the ways in which we would advertise our product, how it would be funded, and why it was even needed in the first place. We also generated some ideas for features that Stakeholders would potentially ant included within the final design, so that we could keep them in mind as we worked through the design process.
Immediately following each interview, the team members that were present regathered on a Miro board to complete Affinity Maps. These were done for all but one of the Interviews, as there were not enough team members present for all of them.
Here, we listed our personal findings from the interview, and what the most important things were that we picked up on. I then had the team call out similar notes that we had made, and grouped them together. These main points, then became the basis of forming our behavior variables and Personas.
.jpg)
Our research up to this point, as well as the foundations for our personas, was gathered and formatted into a formal Research Report. If you would like to see the full report, you may view it below.
Research Report
With our research completed, our team moved into the next phase of GDD: Modeling. In this phase we began working to create Personas; an ideal user type based solely in the research that we have already completed. This helps us to keep our users in mind with designing, as we give each persona type their own set of goals that they would wish to achieve within the application.
Based upon our research, we confirmed our original theory that we would have two user types: a student user, and an event organizer. With this in mind, we began to review our Affinity maps and notes from the research to form behavior variables. We began by listing out common traits and behaviors that the interviewees defined for us and defined each participant on where they fell with the behavior.
Our team then analyzed these points and determined where the common patterns and groupings were. These became the final behaviors that formed our Primary Personas.
Gilbert is a freshman Biology major that commutes to campus every day. He has an odd schedule and has a lot of down time around campus. He enjoys games, but often struggles to find people to enjoy them with. Most of his friends in high school were online friends he made through gaming, but it now trying to find some friends on campus.
Mauricio is a senior Graphic Design major. He is also a commuter student that lives in his apartment just outside of campus. He has grown up with art all his life, and has recently started up a small Digital Art club of his own. He loves being around people, and sharing his love of art and design.
With our personas made and behaviors defined, we were able to start listing the specifics of what our personas would need to walk through the app. We did this by taking one persona at a time, and creating a context scenario.
Each persona was given a context scenario that was formatted in a narrative style story. It was meant to act as a day-in-the-life narrative that allowed our team to give further context to how and why someone would be using the application.
In the context scenario, we walked through the process of how each persona would interact with the app. As we did so, we took a series of notes for each potential screen and need that they would come across.
After both personas had walked through their respective scenario, we consolidated and organized the list. Each persona was given their personal list of needs, and we created a section for their commonalities, and the general requirements that would be needed for the app to function properly.
We then moved fully into the Frameworks phase. For this, we continued working in Miro and began creating wireframes for each Key Path scenario that we had.
Collectively, our team met in a voice call and began brainstorming different aesthetics for the application. Many of us were in agreement, but together we planned the overall feeling of the app and planned some of the core pages together.
With the basic layouts mapped out in Miro for the Wireframe, one of my other team members and I got together and began planning some of the finer details of the application. Together, we went ahead and created the color scheme and began implementing it into the Wireframe so that we would have a better understanding of its visual design when we moved on to prototyping.
To ensure that our process moving forward stayed consistent, I created a style guide as a companion project for our group. This helped define the logo, typography, and brand colors that we would be using throughout the prototype.
Complete Brand Style GuideOnce we had completed our wireframes and defined our key path scenarios, we then moved to Figma to begin our final prototype of OwlsNest. Within this time we expanded on the screens, fleshing them out in greater detail to mimic a working final product. It was in this stage that we also finished with some usability testing, to make sure our product remaine true to the needs of the user.
We began building the prototype by blocking the screens out, similar to how we had built them for the updated wireframe. Several members of the team (including myself) were newer to Figma at the time, and used this process to accumulate ourselves to the application.
Our first goal was to get a low-fidelity prototype that we could present to users. This first draft became a more of a proof of concept with the necessary screens that were defined in our Key Paths.
After we had completed the medium-fidelity prototype, I reached out to a few of the students that we had interviewed earlier in the project. With their agreement, we conducted two usability tests, where the participant was given the link and told to work through a series of tasks. The Team members present monitored their progress through the tasks and where they experienced issues.
One of the largest issues that we encountered with both tests was the organization of the homepage. Both users voiced that they would like more organization and categories to sort the home page, as they believed it would make it easier to find what they were looking for. Our team then returned to working on the prototype, adding in a new system of organization with a horizontal menu for different categories.
The final stages of our process was to clean up the design and add in the details of making the app feel real and used by students. Overall, I am very proud of the final application. We solved various problems, including our main goal of creating a centralized application for KSU's events that was also concise and visually appealing for its users.
The final stages of our process was to clean up the design and add in the details of making the app feel real and used by students. Overall, I am very proud of the final application. We solved various problems, including our main goal of creating a centralized application for KSU's events that was also concise and visually appealing for its users.
This project would never have been possible without the wonderful help from the rest of my team, but together we were able to successfully execute the original idea I had had for OwlsNest.
This project would never have been possible without the wonderful help from the rest of my team, but together we were able to successfully execute the original idea I had had for OwlsNest. As this was my first experience designing a full-fledged application, I was able to take away many skills that I can apply to future projects. The additional benefit of being a Team Lead gave me experience in delegating tasks, organization, and scheduling for both our due dates and various meetings.
