P.E.T Volunteer Management System
Streamlining volunteer management with a smarter, functional, calendar 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
In 2022, we teamed up with and built a web app for a nonprofit called Partners in Equestrian Therapy (P.E.T.), whose goal is to "empower children, adults, and volunteers through a superior equine-assisted therapeutic program"
Role
UX/UI designer - Wireframing, prototyping, usability testing
Team
2 UX/UI designers, 8 devs, 2 tech leads, 1 PM
Timeline
January 2023 - June 2023
Deliverable
A web app that would simplify the process for a volunteer to sign up for a shift, with the goal of reducing the time taken to complete this process by over 40%.
Helpful Links
Figma file
Slidedeck coming soon
GitHub
Official web app
Featured in MustangNews!
Dev tech stack + more
PRD
PROBLEM
Setting up volunteer shifts over text was making it hard for admins to keep track of who was coming in and when.
Before our partnership, admins were communicating one-on-one with volunteers and riders over text and scheduling shifts in Google Calendar manually. This meant that if a shift or session was canceled or needed to be modified, the admins would have to do that manually as well.
The obvious solution would be to look for an online event management tool, but most of the ones available either don't allow multiple people to edit the same event or don't offer separate permissions for different account types like an admin, volunteer, or user.
SOLUTION
We developed a volunteer management system that could keep everyone in the loop.
USER RESEARCH
"A platform that creates transparency between riders, staff, and admin would allow for events to be planned more efficiently."
- Melanie Williams-Mahan, admin
FORMULATING A PRD
To kick off the project, we conducted multiple user interviews with admins from PET, where the primary objective was to better understand what features the web app would need to include. Some of our initial questions were the following:
-
How is scheduling volunteer shifts problematic at the moment?
-
What features in the web app would help solve problems related to scheduling shifts?
We then formulated a PRD. Based on this document, we knew we were going to be making some kind of calendar component with different account types like admins, volunteers, and users, but not much more than that.
Next, the other designer and I reviewed the PRD and simplified the flow diagram the PM and tech leads had put together in the PRD. Our updated version is shown here:
Since we were still unclear on a few aspects of the project, such as how the permissions between volunteer and user account types would differ, the other designer and I made a list of questions that we asked in two subsequent user interviews over Zoom with admins from P.E.T. Some of those questions were as follows:
-
How far apart should time slots be scheduled?
-
Should users be able to see which volunteers are scheduled for appointments and vice versa?
Through these interviews, we gained valuable insight into how to tailer our web app toward the users' needs:
KEY INSIGHTS
COMPETITIVE ANALYSIS
Since we knew the most important interface in the web app would be the calendar, we wanted to ensure our design seemed familiar and wouldn't be a huge leap from other industry standard calendar apps. Google and Apple Calendar were the two we focused on.
The primary focus of our competitive analysis was to answer the question, should the time slots be displayed in a daily, weekly, or monthly view?
Google Calendar
-
Simple, clean interface
-
Default view is weekly
-
Time ranges are visible
We determined that a weekly view would be optimal for our web app because it could show upcoming events with the time on the slot still visible. This also afforded us the opportunity to integrate a smaller calendar widget off to the side for easy navigation.
DESIGN EXPLORATIONS
We began the ideation phase of the design process by borrowing some low fidelity designs from the Figma community for our calendar. This helped us visualize how we would approach the account types component to the web app, since we realized the admin should be able to filter between volunteers and riders, or both.
The next feature we wanted to address was the time slots, and how admins would go about making changes to them or deleting them in the event that the shift had to be canceled or rescheduled. Our initial idea was to allow admins to permanently delete slots using a trash option, but the admins' non-technical background was a bit worrisome and we were concerned that they might struggle to add a slot back if it was deleted accidentally.
This concern actually sparked the realization that the P.E.T. admins might prefer an extra confirmation step that users who are more familiar with technology would see as redundant. So, instead of simply asking the user to "save changes" after deleting selected slots, we prompted users to confirm that making any kind of modification to a slot was actually their intention before they could executive the action.
IMPORTANT CHANGES
Our final iteration of the time slots popup featured toggles to disable or enable a slot. This way, It would be more difficult for an admin to accidentally remove a slot and it minimized the number of clicks to add it back.
As we moved into high fidelity, we also developed a consistent branding scheme to apply to the web app, using P.E.T's signature aqua as the primary action color.
We also quickly realized that time slots would have different states, including a default state for unaffected slots, (aqua), a full state for slots where the maximum number of users had already signed up, (light aqua), and disabled for slots that had to be canceled due to weather, holidays, etc. (missing for user and volunteers, gray for admins).
FINAL PRODUCT
MOBILE VERSION
Using graceful degradation, we built a mobile version with the same functionality.
2. Flexible viewing for admins
3. Manual control
1. Flexible viewing for users
We were fortunate enough to have the time and resources available to build a dedicated mobile version for this project, which we designed by scaling down the desktop version into a mobile friendly interface. I took the lead with this portion of the project as the other designer had to step away for a period of time due to a health concern.
The mobile version features all the same functionality with only minor differences like the filters for account types being replaced with a convenient drop down menu.
USABILITY TESTING
Hearing the admins say "user-friendly" was music to our ears.
We conducted a round of usability testing with our MVP with admins from PET involving four sequences of tasks: filtering visibility on the calendar, viewing the time slots popup, disabling a time slot, and signing out. We tested both the desktop and mobile versions.
In lieu of the more traditional usability testing method where users are given a task and then minimal feedback, we thought it would be best to walk the admins through the Figma prototype and prompt them for feedback as they navigated it, given their non-technical background.
We were happy to see that 100% of the participants called our web app "user friendly" and had a high task success rate.
OUTCOMES
Here's what we accomplished.
1. Reduction in time taken to schedule a volunteer shift exceeded our goal of 40%
2. 100% of the users we tested found it to be intuitive and the task success rate was very high
3. We did something meaningful for our community by helping those in need
4. Featured in MustangNews!
REFLECTIONS
Here's what I would do differently.
Here's what I would do differently.
This was my first UX project working with a real client (woohoo! 🥳), and while I was immensely proud of the fact that we were able to deliver a product that met all the client's needs, there are still some things I could have done better.
1. Don't be afraid of bad ideas. It wasn't until the back half of the project when we came up with the toggles idea. In the earlier stages of the project, we could have taken more time to ideate and throw out a bunch of ideas in order to explore a wider variety of solutions, and potentially arrive at the right solution faster.
2. Advocate for your ideas. During this project, there was limited communication between the designers and the developers. As a result, the web app that was ultimately developed in code wasn't exactly 1:1 with the Figma file.
3. Usability is determined by the user. Although at the time we thought it made sense to conduct our usability testing session by walking the admins through the prototype, a fatal flaw with this approach is that it looked more like a final design and the admins were likely hesitant to provide constructive feedback as a result. Making sure you aren't priming a certain response from the user is critical to understanding what the user really thinks.
STYLE GUIDE
Thanks for reading!
That's it from me. Some important links again just in case you missed them at the top!
Slidedeck coming soon