Transforming Lagos Food Bank Initiative’s Approach to Volunteer Management
Timeline: Spring 2023, Fall 2023 (8 months)
Team: Cornell Hack4Impact
- Project Managers/Leads: Jason, Akin
- Designers: Bella, Ella, Mika
- Developers: Louis, Daniel, Sneha, Sophie, Yichen, Hannah
Client: Lagos Food Bank Initiative (Lagos, Nigeria)
Client Background 👥
Lagos Food Bank Initiative (LFBI) is a non-profit organization based in Lagos, Nigeria, with the mission of alleviating malnutrition in Nigeria’s communities. According to UNICEF, 25 million Nigerians are at risk of food insecurity in 2023. In response, LFBI provides nutrition-focused programs to combat hunger and reduce food waste. The Food Bank has over 24,000 registered volunteers and there have been over 2 million beneficiaries impacted by their work.
The Problem 🤨
Lagos Food Bank Initiative runs 8 programs and manages 19,000 active volunteers, who they rely on for events. However, their current system for managing volunteers is labor intensive and time consuming. The organization currently uses multiple platforms to manage their events and volunteers, including: Mailchimp, Google Forms, Instagram, and WhatsApp.
The Solution 🔍
To help LFBI efficiently manage their large volunteer base, we created a volunteer management web application to facilitate volunteer signup, event management, the tracking of volunteers’ hours, and more. We created this web app with three user types in mind: volunteers, who can browse and sign up for events; supervisors, who can manage volunteers and create events; and administrators, who can manage volunteers, create events, and edit the website’s metadata.
User Research ✍️
To understand the user journey for signing up for an event and creating/managing an event we interviewed 2 volunteers, 1 program officer, and 1 LFB admin team member. These are our insights:
Volunteers:
- Check-in lines at events can be very long, check in during events are on paper after having a list of people who RSVP-ed
- It takes 2 weeks to get a reference letter
Program Officers (Supervisors):
- Manual check in takes a lot of time and effort
Administrators:
- A major pain point is having to manually search for a volunteer’s volunteer history through our attendance books, and this process can take a minimum of two weeks.
Thus, in our solution we aim to provide a way to make the check-in and reference request processes more efficient.
Design Decisions 🎨
1. Recurring Events
LFBI has many recurring events. As such, we needed a way for supervisors to create recurring events in a more streamlined way than manually creating the event from scratch every time.
Option 1: Repeating Occurrences Dropdown
Pros:
- Set it and forget it
- Familiar: creating a repeating event follows the same format as calendars and alarms
- Integrates seamlessly into event creation form
Cons:
- Less feasible for devs with our time constraints
Option 2: Template Format
Pros:
- Integrates seamlessly into event creation form
Cons:
- Less future proof: what if the client wants to create a new recurring event or stops holding an event permanently? Client cannot create a new event template themselves post hand-off because it would need to be hardcoded in.
- Less feasible for devs with our time constraints
Option 3: Event Duplication
Pros:
- Easy for dev feasibility
- Easily integrates into Past Event Details page
Cons:
- Nested within another page, could be hard to find
Final choice: Event duplication (option 3) was our final choice. While we initially thought that the template option was best since it seamlessly integrated into the event creation form, this would be difficult for the devs to implement given our time constraint for the semester. So, we chose the second best option, instead—event duplication.
2. Upcoming Events Page
The events page is where volunteers and supervisors would access their events. We explored different options of how to organize event cards, and display them to users.
Option 1: Card Layout
Pros:
- Many events are visible at the same time
Cons:
- Too many options — overwhelming for users according to Hick’s Law
- Difficult to discern which event is happening the soonest
Option 2: Timeline Layout
Pros
- Events are clearly chronologically sorted by date/time
- Reactive cards possible: able to indicate which event is happening today
Final choice: The timeline layout (option 2) was our final choice because it clearly displays the chronological order of events. Additionally with the design of the timeline layout, it was possible to make cards reactive as a call to attention, showing users which event is happening that day.
3. Volunteer Profile Page
After developing a more solid design system, we looked back at the actual structure of our pages. We agreed that the profile page in particular felt too “nested” — it had four tabs with little information under each. We decided instead to put all of the information onto one page in a card format.
Initial Design
Pros:
- Clear sectioning of content using tabs
Cons:
- Little information on each page, defeats the purpose of the tab format
- Feels too nested, more clicks than necessary to get to a section of the page
Final Design
Pros:
- Clear page structure
- Less clicks for the user, more efficient overall
Cons:
- More scrolling involved for the user
4. Reducing Whitespace and Shifting the Background
As we were working on our hi-fis throughout the semester, we iterated on the UI of the web app, as well. A significant design decision was looking at how we wanted to represent the overall “look” — this mainly included shifting background and accent colors.
Iteration 1: Too much whitespace
Pros:
- Clear and consistent page structure
Cons:
- Little color, too much whitespace
- Doesn’t look like a hi-fidelity page, resembles a mid-fi because of the lack of color and design refinement
Iteration 2: “Template” background
Pros:
- Less whitespace, more refined look
- Better “View Profile” button format
Cons:
- Looks less professional
- Not similar to many competitor websites, unfamiliar design
In this next set of iterations, we attempted to combat the whitespace issue by creating a “template” format where we incorporated a different background color behind a white centered box that contained the content. The most obvious positive of this format was the reduction of whitespace, but a con that we found was that this format looked “cheap,” “elementary,” and overall less professional. This was also not a design that we saw on many competitor websites, and we wanted to maintain familiarity for our users of varying tech literacy levels.
Iteration 3: No template, gradient background
Pros:
- More color
- Clear sectioning of content despite not having the “template”
Cons:
- More professional look overall
- More similar to other websites, adheres to common design patterns
After looking more closely at competitor websites and designs, we implemented a slight gradient background to our pages — we thought that this moved our designs from “elementary” to professional. We kept the white background for all of our forms, for example when creating an event or for our instances of tables. This keeps to a design standard and makes sure that everything is as clear and visible as possible.
Drumroll please… The Final Product! 🎉
Try out our prototypes to see more of each design flow!
Design System 🎨
We created this design system in order to follow the atomic design method, where each component could be used to form the larger interface. Once we had this finalized, it made our hi-fi development much more efficient.
View the full design system on Figma.
Reflection 💭
What we learned
During the Fall 2023 semester, we were primarily focused on pushing screens to the high fidelity stage, which came with its challenges. It took us multiple iterations to land on visual designs that we were happy with. We learned that visual design is an iterative process, and to question visual designs from mid-fis when pushing to high fidelity screens.
While creating high fidelities we also learned the importance of a design system, which we learned to create and developed with atomic design in mind. We also learned the importance of prioritizing features for MVP due to the large scale of the project.
What we would do differently
If we could go back, we would have decided on the visual design first before we began pushing screens to high fidelity. Since we didn’t do this, we wasted time changing high fidelity screens each time we made a general visual design decision.
Thank you to everyone who helped us along the way!
