SLO Beaver Brigade
Kicking event management into high gear with a dynamic calendar and dashboard system
Project Overview
I work at Hack4Impact a "501(c)(3) organization that empowers engineers, designers, activists, and humanitarians to create lasting social change by developing projects for local nonprofits." - H4I Cal Poly
Role
UX/UI designer - Wireframing, user research, onboarding
Team
In 2023, we teamed up with and built a web app for a nonprofit called the San Luis Obispo Beaver Brigade, who manages five beaver habitats in San Luis Obispo County. - slobeaverbrigade.com
Deliverable
A web app that would digitize 3 key processes: scheduling volunteer shifts, signing waivers, and tracking volunteer hours with the goal of reducing time spent on each by upwards of 50%.
4 UX/UI designers, 9 devs, 2 tech leads, 1 PM
Timeline
November 2023 - June 2024
Helpful Links
Figma file
Slidedeck coming soon
GitHub
Official web app
PRD
PROBLEM
Recurring processes like scheduling shifts were time consuming and needlessly complicated.
Before our partnership, prospective volunteers would fill out an interest form with their contact info and availability. Then, an admin from the SLO Beaver Brigade would reach out and coordinate a specific time for them to come in.
Signing a waiver was another bottleneck in the process to start volunteering, since this had to be done in person and on paper, leading to thick file folders that made it hard to quickly dig up specific information.
As a nonprofit, the SLO Beaver Brigade frequently applies for grants to sustain their daily operations, and a key metric they use in these applications is the number of hours their volunteers accumulate. This process was also being carried out on paper, which again made it difficult to reference specific information at any given time.
SOLUTION
We synthesized all of these needs into an online portal where everything was in one place.
USER RESEARCH
"We have technical needs that we either don't have the solutions for or don't have the time to develop a solution."
- Audrey Taub, admin
FORMULATING A PRD
To kick off the project, our team conducted multiple user interviews over Zoom with the admins, during which they were primarily concerned with the systems that were currently in place and how they envisioned those systems would be improved. Some of our initial questions were as follows:
-
What pain points can we help you address with this web app?
-
What are some important features that you would like to see in the web app?
-
What impact are you hoping the web app will have on your organization as a whole?
We then worked together to form a PRD. Based on this document, we knew we would be making some kind of calendar system for signing up for events, as well as a dashboard where those events could be managed.
Additionally, we knew our web app should support digital waivers, as well as some kind of digital tool for tracking volunteer hours. This was good news, because from the very beginning we knew we were addressing all three of those major pain points mentioned above.
USER INTERVIEWS
After some initial brainstorming with the other designers, we circled back with the admins three more times to conduct user interviews and get a better understanding of each feature's functionality. Some of our questions from these rounds were the following:
-
How are users signing up for events at the moment?
-
How does the waiver signing process work and how could it be improved?
-
What kinds of different volunteering opportunities are users signing up for?
KEY INSIGHTS
FLOWCHART
Using these insights, we constructed flowcharts in FigJam for the various components and account types that the web app would include (admin dashboard, user waiver, etc.) Shown below is the diagram for accessing the user dashboard, which accounts for if they were signed in already.
COMPETITIVE ANALYSIS
The potential for integrating third party apps
Since we knew the dashboard and calendar were going to be the two major interfaces for our web app, we took a look at other industry standard calendar apps like Google and Apple Calendar to ensure that our design would seem familiar to users.
Along the way, I noticed Calendly checked all the boxes in terms of functionality for our project (ability to change event type, email reminders, etc.)
-
Automated email reminders
I was advocating for embedding their software into our web app until we read about the monthly subscription cost end decided to scrap the idea. This ended up working in our favor because we were able to link our custom dashboard to the calendar system we ended up building.
Calendly dashboard
-
Different event types
-
Recurring events
SKETCHES
To kickstart our creativity, we made some quick sketches that we imported into a FigJam board for ideation. The main goal here was to experiment with how best to implement some of the core features from the PRD, including the option to create an account, a filter for event type, and so on.
DESIGN EXPLORATIONS
As we moved into low and mid fidelity, we ran into a lot of questions related to how the user would navigate the web app, such as should they be required to have an account in order to register for an event? In order to simplify the registration process as much as possible, we agreed that an account would be optional.
Another somewhat daunting task was creating an authentication system for the volunteer hours. In order to ensure that volunteers were being awarded the correct number of hours, designed the tracking tool to automatically add the number of hours equal to the duration of the event to the corresponding user profile.
Then, admins would be allowed to manually adjust the number of hours if a volunteer didn't show or the event was canceled or modified.
IMPORTANT CHANGES
A big challenge that we tackled in the final iterations of the project was the inconsistent branding. With a team of four designers all working on separate components, the typography, color scheme, and content hierarchy were commonly mixed up. In our final iterations, we were able to consolidate many of our ideas into something more consistent.
Something new we tried this year that I really enjoyed actually was getting to work 1:1 with the devs. Previously, the tech leads had been assigning devs individual tasks in GitHub usually involving a single component like the pop-up modal on the calendar.
This time around, the designers and I had the opportunity to sit down next to the devs as they coded, allowing us to take on more of a quality assurance role. This meant ensuring the right hex code values were used, font sizes and border radius, etc.
FINAL PRODUCT
REFLECTIONS
Here's what we accomplished.
1. We met our goal of reducing the three processes the admins had identified as pain points by 50%
2. We were able to digitize three recurring processes, future-proofing that information
1. We helped a new nonprofit streamline their workflow
REFLECTIONS
Here's what I would do differently.
While the team spirit for this project was off the charts (go beavers! 🦫), there were still some areas where we fell short.
1. Communicate with the devs CONSTANTLY. During this project, the developers worked very efficiently and occasionally were assigned GitHub tasks that involved components that the designers hadn't built yet. This sometimes led the devs to create their own designs, and put us in the uncomfortable position of needing to choose between designing around what they had made or asking them to scrap their idea.
2. Stay informed on designs that others were assigned as well. I often felt disconnected with the other designers on this project because there were four of us and four major components that needed to be built (admins/user dashboard, calendar, hours tracking), so it made sense to have everyone work on mostly one feature. This was a major contributor to the inconsistent branding and made it feel like I was always a little out of the loop.
STYLE GUIDE
Thanks for reading!
That's it from me. Some important links again just in case you missed them at the top!