Squirrels (UX)
SQUIRRELS
The one-stop hub for easy university event discovery and registration
My Team
a team of four students undertaking a project for an undergraduate class at the University of Toronto called “INF352: How to Design”
My Role
user research, project management, design, illustration
Tools
Adobe Illustrator, Adobe Photoshop, Adobe XD, Balsamiq, Clip Studio Paint, DaVinci Resolve, Google Suite, Microsoft Powerpoint, Xtensio
Methodologies
interviews, surveys, literature reviews, data analyses, affinity diagrams, personas, empathy maps, as-is scenarios, needs statements, prioritization grids, to-be scenarios, hypothesis tables, paper prototyping, sequential storyboards, wireframes
Chapter I: Discovery
The Problem
The University of Toronto (U of T) lacks a centralized platform for finding and discovering relevant U of T related events, which could be a reason why many U of T students are disengaged from the U of T community. To validate our assumptions, we decided to do both primary and secondary research, which lasted a little less than two weeks.
The Research
Surveys are useful for quickly gathering attitudinal and quantitative data, especially in such a limited amount of time. After diverging and brainstorming on the questions for our Google Forms survey, my team and I converged and collectively chose the most suitable questions to include in our survey.
Afterwards, all team members shared the survey forms online. My one other teammate and I also conducted in-person surveys around Robarts Library and Sidney Smith Hall in Toronto, where we personally asked students to fill out the surveys. In total, my team managed to survey 65 students.
We chose to conduct semi-structured interviews to gain a deeper understanding of the students. Although interviews can be time-consuming (each interview lasts about 30 minutes), interviews are useful for gathering attitudinal, quantitative, and qualitative data.
After collectively brainstorming possible interview questions to ask other students, my team and I synthesized the questions into one form, along with other documents like the study protocol and the recruiting screener. I conducted three in-person interviews out of the team’s eight total interviews.
From our secondary research, which ranged from scholarly articles to the online forum Reddit, we discovered that the lack of student engagement is an issue at Canadian universities, especially at U of T. Descriptions such as “culture of isolation” came up when students described U of T.
Adding to that is the fact that many non-native English-speaking international students at Canadian universities may experience language difficulties and culture shock, which could impact their engagement with the overall student community. U of T consists of about 23% international students, so this problem may be elevated there.
Chapter II: Interpretation
From the data gathered from the open-ended surveys and interviews, we started performing our qualitative data analysis. We started by highlighting the key points from the open-ended surveys and interviews, and then organizing them into affinity diagrams using sticky notes. After determining common themes, I digitized the sticky notes using Photoshop to make them easier to read. After, I organized the themes into tables and ordered them based on their frequency counts.
The affinity diagrams show that there are many different reasons why students choose to attend events, including to network and to gain new experiences. However, there are also many reasons why students choose not to attend events, schoolwork and time being the most common reasons.
When asked for ways to better improve student engagement on campus, participants provided numerous ideas, including targeted advertisements, free food, email reminders, and knowing whether their friends are attending.
One of our affinity diagrams based on user interview results.
Our affinity diagram based on open-ended survey results.
Then, we performed our quantitative data analysis based on the survey results, which we transcribed into pie charts and bar graphs. Some of the most important discoveries we made were that most students rarely participate in events (less than three times per semester), and that event promotion seems to be a huge problem, since students mainly find interesting university-related events from their friends.
Based on our findings, we created a proto-persona of Shannon Anderson before developing her more into a polished persona on the Xtensio platform. To ensure that we truly understood and that we achieved a better overview of Shannon, we also created Shannon’s empathy map. Throughout this process, we made sure to make great use of our data when developing Shannon.
The polished persona, created on Xtensio.
Shannon’s empathy map.
To gain a better understanding of Shannon’s problem, we developed an as-is scenario that imagined Shannon’s current journey when she searches for, signs up for, and attends university-related events. My team and I each imagined what Shannon would be doing, thinking, and feeling throughout her journey, and individually inputted them on a Google Sheets table. Upon completion, I helped determine areas of opportunity by facilitating a voting process, in which we each voted on what we perceived as the most critical problems Shannon had.
The main problems we found were Shannon’s difficulty in finding events of interest and the overwhelming number of decentralized event platforms. Some minor problems we identified were worries about fitting in to the event crowd, time conflicts, and insufficient event details.
Shannon finds an event
Shannon is overwhelmed and confused about the seemingly never-ending stream of events and decentralized event platforms. She thinks, “Why are there so many events and event platforms? My precious time…”
Shannon registers for an event
Shannon is irritated that she has to fill out so many information sheets whenever she wants to register for an event. She thinks, “I swear, if I have to fill out another information sheet!”
Shannon attends an event
Shannon feels embarrassed and awkward when she attends the event. She does not know anyone there, and they all seem to already know one another. She thinks, “Where are my friends? Come to think of it, I don’t event know if they’re attending this event. This is all too much for me, I should just go back home and study.”
Chapter III: Ideation
From Shannon’s polished persona, as-is scenario, and pain points, we developed Shannon’s need statements, which relate back to the problem my team wanted to solve. Based on the need statements we created, we determined that to save her time and frustration, Shannon primarily needed the ability to easily find and discover events of interest in one convenient location. She also needed to be able to see who was participating in an event, to check whether her friends or classmates were also attending. Finally, she would also greatly benefit from being able to find event details, such as if there are free food or dress codes at the event, so that she could better prepare herself for the event.
Then, my team and I each generated four ideas to address Shannon’s pain points. I brought four ideas to the group, which were:
- Sticky Bug – Latches onto people you connected with at the event and gives you their name and contact details
- Food Hollerer – Screams whenever there is food at the event
- Friend – Invites you to events that you may be interested in
- Net – Only catches events that relate to your needs and/or interests
The clustered ideas were each rated based on impact and feasibility.
My team and I then voted on the ideas based on their impact and feasibility, before organizing them into a prioritization grid. From the grid, we clearly saw which ideas garnered the most votes. The top idea ended up being the ability to integrate with the students’ UTORids (their university logins), to allow for seamless event registration.
However, we were also careful not to discard our absurd ideas! (I had quite a lot of them, too). As Elaine Camper’s short story “The Honey Pot” demonstrated, absurd ideas could also turn into wonderful ideas. In the end, we were able to tweak some of the absurd ideas. In fact, my absurd ideas are now core parts of the app in slightly different forms!
Chapter IV: Experimentation
My team and I created Shannon’s to-be scenario, which captured what Shannon would be doing, thinking, and feeling when using our solution. Our to-be scenario addressed Shannon’s pain points when she is finding, registering for, and participating in an event.
Here were some of the pain points we addressed:
How the pain point is addressed: Shannon can use one platform to search for all of the events, the app can give her recommendations based on her interests, and she can use the filter to search for specific types of events.
How the pain point is addressed: The app filters events based on interests that Shannon has selected in the initial app sign in process.
How the pain point is addressed: Shannon can save time by not having to go through a tedious process when looking for events to attend. She also saves time due to the one-tap registration process. This allows her more time for higher priority activities.
How the pain point is addressed: The app’s integration with UTORid allows a one-tap registration process that automatically verifies and receives the participant’s name and email.
How the pain point is addressed: All the necessary information pertaining to the event (e.g., map, organizer, dress code, details) are integrated on one screen on the event details page.
Afterwards, we created a table of hypotheses with user-centered statements, which helped me and my team design Shannon’s solution. From the table of hypotheses, we came about five features that would help make Shannon’s journey better, specifically to make it easier for her to find and register for events:
- A scrollable home screen that shows events related to Shannon’s interests
- A searchable participant list to let her know if her friends are attending an event
- An in-app one-click registration button that is integrated with her UTORid, so she could easily register for events
- An app page that lists all of the events she has been registered for, so that she could easily track her events
- A map feature within the app, so that she could easily see where her event is located
Then, we got started on our low-fidelity prototype! With the help of my team, I drew the prototypes on Clip Studio Paint. I also created the low-fidelity sequential storyboard using Microsoft Powerpoint, as well as carved a fake smartphone out of foam board to give our representative users a richer experience while doing the lean evaluations.
The low-fidelity storyboard.
A fake foam board smartphone for the lean evaluations.
Before conducting our lean evaluations for our low-fidelity prototype, we first converged and agreed upon some questions we would want to ask our participants. The questions we included revolved around what the participant thought worked well, what new ideas they might have for our app, and the things they thought should be changed. We planned on evaluating in groups of two, with one member asking the questions and the other member observing and writing down comments made by the participant.
A teammate and I then evaluated participants at public spaces on the U of T campus, such as the Robarts Library and the Inforum. My teammate and I evaluated three participants together, while my other teammates evaluated two. In total, my team evaluated five participants, which is sufficient as according to Jakob Nielsen, five test users can already find about 80% of the product’s usability problems.
Our lean evaluation gave us ideas for ways we could improve our app. Some of our logos and icons caused confusion amongst our users, and some, like the ones in the lower menu bar, could be labelled for clarity.
App sequence and hierarchy also came up. For example, one participant mentioned that upon clicking “I’m Done,” she expected to go back to the “Anime Party” page instead of “Your Events.”
Some evaluation participants were unsure about why only the first names of event participants were listed. After telling them that it was for privacy reasons, most liked that idea. However, some still wanted a better way of identifying who the people attending the event are.
New feature ideas were also mentioned, such as the ability to add an event to a favourites list and control when they receive event reminders. Finally, participants also mentioned that having the event’s date and time added to the event registration confirmation page would be useful.
The feedback from the low-fidelity prototype lean evaluation was considered carefully and weighed out with other options. For example, since many participants really liked the privacy aspect of having only their first names shown on the participant list, and a participant expressed that there may be some confusion associated with having only their first names showing (for example, what if there are two Kevins?), we decided to form a compromise by keeping first names only, but also allowing users to search the participants list by program (for example, Life Sciences).
My team and I then created the clickable mid-fidelity prototype on Balsamiq. We also created our mid-fidelity sequential storyboard on Powerpoint. On Balsamiq, I was mostly in charge of linking the screens, helping to design the home screen, designing the participants list, event confirmation page, and user events page, and organizing and re-aligning the objects on all screens.
Our mid-fidelity prototype, created on Balsamiq.
Upon creating our mid-fidelity prototype, we proceeded to conduct usability evaluations. Our method for this was quite similar to that of our lean evaluation: we conducted our evaluations in pairs, with one group member asking the user questions and the other member observing and writing down comments made by the user. We also talked to a total of five evaluation participants in Robarts Library and the Inforum, who we asked to complete certain tasks and think out loud while completing the tasks.
We asked the users to complete the following three tasks:
- Register for the Anime Party event.
- Look at the participants list for the Anime Party event and perform a search.
- Make the Anime Party event a favourite and then find it in your favourites.
Most participants found our prototype easy and pleasing to use. They liked our app idea, some even stating that it would help make U of T a more involved community.
The participants made some comments that we would also deeply consider when we iterate our prototype again. The comments include providing more details about the event location, providing the ability to automatically add events they registered for to their personal calendars, and providing the ability to customize their profile, such as adding a profile photo or changing their names.
Chapter V: Evolution
My short high-fidelity prototype, created on Adobe XD.
Throughout the project, we learned how important it was to avoid relying on self-referential information by conducting primary and secondary research to test our assumptions, ideas, and/or products. Diverging and converging also proved to be useful tactics to not only generate as many ideas as possible (which would then translate to some quality ideas), but also allow all group members to be heard.
Although the current Squirrels could be a good solution for U of T students to easily find relevant university-related events, we also initially hoped to include a feature that would allow students and administrators to easily post events to our app. However, due to time constraints, we only managed to focus on researching the event participants. In the future, we definitely want to develop Squirrels more so that it is also optimized for event organizers. That means creating a separate persona, empathy map, and journeys for event organizers. For now, as seen in the high-fidelity screens I created using Adobe XD, I added a “Create Event” button that allows students and event organizers to post their events on the app.
Our usability evaluations gave us more ideas of what kinds of features and changes we could add to our app. The most important one revolved around privacy. We wanted to tackle privacy concerns surrounding the event participant list by providing users the ability to change their legal names to a pen name. This ability to change names is reflected on my high-fidelity screens, namely in the home screen where the user chose to change their name to “Potato,” as well as in the event participant screen where some participants are seen with pen names. We also considered implementing the ability to opt out of appearing in the participant list. For the high-fidelity screens, I chose to still include “invisible participants” in the participant list, but their names and programs are replaced by “Anonymous” and “Ninja,” respectively.
Some high-fidelity mockups of Squirrels.
Other feature ideas from the usability evaluations that are now in the high-fidelity screens include the replacement of the favourites feature to a bookmark feature, as well as upfront details of whether or not an event is free. Upon consulting a representative user concerning our mid-fidelity prototype, I also realized that we forgot to add the day of the week on the app, which is important especially for university students, as they are bound by their timetables that vary depending on the day of the week. I have since added the day of the week to the high-fidelity screens.
Some features we wish to have in the future include the ability to save events to personal calendars and the ability for users to add a plus one. However, we want to remain secure so that would probably require the user’s plus one to confirm their phone number or undergo other security measures.
Overall, I think that during the four months that we worked on this project, my team and I did our best to make Squirrels as centered around university students as possible. In doing so, I believe we designed an app that would hopefully, if actually developed, drastically improve student life on campus.