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.
- Melanie Williams-Mahan, admin
How is scheduling volunteer shifts problematic at the moment?
What features in the web app would help solve problems related to scheduling shifts?
How would those features differ based on account type?
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:
What features in the web app would help solve problems related to scheduling shifts?
Should users be able to see which volunteers are scheduled for appointments and vice versa?
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?
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.
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.
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).
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
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 built a scheduling solution for a nonprofit that really needed our help.
We fulfilled our mission of building software for social good, allowing PET to better serve the SLO community.
Featured in MustangNews!
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.
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.
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.
That's it from me. Here's some more helpful links: