🎯 OVERVIEW
This project was an amazing opportunity with Study Break↗, a start-up that aims to connect UCLA students to on-campus organizations and events based on interest and location.
How could the user flow of Study Break’s mobile app better engage its target audience of college students? To answer this question, our team conducted a formal case study through interviews and market research, ultimately identifying pain points to inform our redesigns. Our final deliverables were high-fidelity wireframes that kept elements from Study Break’s existing branding systems, and a comprehensive report of our research findings.
moodboard + sketches
❓Finding and posting events on Study Break was confusing.
Our team interviewed 5 undergraduate UCLA students—3 of whom held club leadership positions— to understand what would encourage a wider audience of college students to engage with the app. We included student leaders in addition to regular students as clubs contribute to almost all events in the Study Break database; thus, club leadership would be the main end-users posting events.
To begin, we faced the interviewees with task-based questions such as “Pretend you’re a student trying to find the event “Creative Collective”. How would you go about finding this event?” These questions allowed us to observe any recurring challenges in the most common user flows of finding and posting events.
“I can’t find the page to
post something.”
Volleyball Club Officer
“This is a lot of effort to
find one event.”
3rd Year Student
“I’m not sure what this
shield icon is for.”
Medical Club IVP
1️⃣ Vague in-app language and uncommon icons made it hard to determine which features were where.
Many of the students made comments on icons upon entering Study Break; for example, they expressed surprise at the star in the navigation bar, which they did not expect to be “Attendance“.
4/5 students also showed uncertainty about the purpose of shield icon on the groups page. All 3 student leaders wondered whether clicking it would lead them to the event-posting page, or something unrelated.
2️⃣ Nested pages were overcomplicating the search process.
Originally, the Discover page was designated for events, containing a map/list view toggle, and a “Go Virtual“ button. However, the search button took students to another page, where all those filters disappeared, and students could only sort by “Today“, “Tomorrow“, or another selected date. Students were interested in filtering and searching simultaneously, but couldn’t.
Furthermore, in the process of looking for a specific org, 2 students came across a search page in the “Explore Groups“ section, and questioned why it was separate from the main search.
3️⃣ Study Break was lacking communication features essential to students.
Aside from the task-based questions, our team also asked about students’ current habits; Instagram was repeatedly cited by interviewees as their most-used platform for events. While it’s not necessarily used to discover new communities, the convenience of sharing to stories makes it popular for established communities, who can then advertise and update followers quickly. This was echoed by students who mentioned Discord for its ping system.
summarized notes from our team’s competitive analysis
❌ Students weren’t sure if they would use Study Break again with its existing features and design.
Overall, the students agreed that the app was difficult to maneuver due to a variety of reasons—while most students did complete the task of finding an event in the end, they expressed frustration that it took so long, and that this would deter them from utilizing Study Break for this purpose. With these issues in mind, our team became guided by the following questions:
A
How might we make finding events more straightforward and enjoyable?
B
How might we make the event posting process more
accessible for student leaders?
C
How might we decide which features are crucial and which are not?
🖽 Wireframing lo-fi solutions
My goal in the lo-fi stage was to minimize redundancy in the home and groups page— specifically, I considered how the navigation bar could either be reorganized more clearly, or reduced down to 3 sections.
I also considered which features could be moved to settings rather than taking up room on the more prevalent main pages. Things that came to mind were Admin and Moderator Roles and Create Group, which would need to be accessed far less often than pages for finding and posting events.
the earliest stage of ideation
⚠️ However…
After a week or two of making low-fidelity sketches, our team ran into a problem. We had divided the app up into multiple sections to design separately due to our tight timeline of 10 weeks, but everyone was imagining the wider user flow of the app differently— which was causing inconsistencies when we tried piecing the sections together.
With consideration to the fact that we only had a few weeks left, we decided to regroup and define the main user flow together before making more wireframes.
A user flow that our team came up with for consistency while designing!
🔄 Iterate, iterate, iterate!
After a week or two of making low-fidelity sketches, our team ran into a problem. We had divided the app up into multiple sections to design separately due to our tight timeline of 10 weeks, but everyone was imagining the wider user flow of the app differently— which was causing inconsistencies when we tried piecing the sections together.
With consideration to the fact that we only had a few weeks left, we decided to regroup and define the main user flow together before making more wireframes.
Mid-fi for posting an event
💬 Feedback
However, my team gave feedback that this button could cause confusion. Is it a button to post events, or to create a new group? Moving it to another location would be more ideal, despite the original function being located in the Groups section.
I then moved the post button to the Discover page, which also went through multiple iterations based on feedback and our research conclusions— namely, adding a way for clubs to communicate updates and more through “Announcements”.
This Discover page sought to solve the problem of making event-finding less tedious. Everything would be centralized on a dashboard, where happenings would be recommended to users based on their interest, and the previously-mentioned announcements from groups would push any events from students’ existing clubs.
Iterations vs. the fial solution
🎁 Wrapping it up
Unfortunately, given our short collaboration, there wasn’t enough time for the Study Break developers to commit these design revisions in-app for more user testing before our contract was up. At this point we exchanged any last feedback, then handed off our final wireframe solutions to the Study Break team for development and to be shipped at a later date.
🤔 What I learned
This project was my first ever UX case study, and definitely taught me that user research is no quick task. There’s so much to be considered behind the simplest decisions. and coming up with solutions requires a lot of trial and error.
The thing that stuck to me most is that the UX design process isn’t linear. You may explore one route that has unforeseen issues later on, like our team did when we split up sections to design separately. I learned it’s okay to retrace your steps, and redo parts of the process in order to keep moving again— like us scrapping our individual wireframes to come back and reconsider the wider user flow as a team. And also, to make sure you have a lot of options, iterate, iterate, iterate.
Thanks to Taylor and Serena for guiding our fledgling team through the entire process. There was so much to cover from componentizing things on Figma to standards for mobile app design, but you taught us that and so many other basic skills we’ll use for the rest of our design careers.
