Vouchers 4 Veggies — EatSF (V4V) is a San Francisco nonprofit focused on increasing the accessibility and affordability of healthy foods for low-income households. Free vouchers are distributed to buy fruits and vegetables at grocery stores, improving the overall health of people and reducing food insecurity. Grocery stores — with faster produce turnover — are also able to restock produce more frequently and display greater variety and quality.
The Problem 🤔
Many people from low-income households have expressed that they want to eat more fruits and vegetables, whether that’s to stay healthy or to help them manage their chronic disease. However, fresh fruits and vegetables are often financially beyond their grasp. Even with food programs, many often fail to provide enough resources to properly include healthy foods in the diets of low-income households.
To combat this, V4V partners with a network of community food distributors, corner stores, grocers, and farmer’s markets to provide free vouchers to these households. However, vendors process vouchers manually, an extremely tedious and time consuming task that is subject to human error. Therefore, V4V’s biggest problem is inefficiency.
The Solution 💡
Blueprint is partnering with V4V to streamline the processing of vouchers between participants and vendors while keeping vendors updated on the status of their invoices and reimbursements with a mobile app.
After a vendor scans a voucher for a transaction, the vendor will be able to:
1. Verify the value of the transaction.
2. Update the value of all used vouchers.
3. Update data for the invoice to get properly reimbursed by V4V.
Audience 😸
There are two users involved:
- Vendors in the V4V Program are the primary users. Through the app, vendors are able to scan vouchers and update invoices for transactions, view invoice history, request an invoice, and then view reimbursement status for that invoice.
- V4V Admins are the secondary users. These users have access to a web dashboard where they are able to view the list of current vendors with information on pending invoices and invoice history, approve or deny new vendor accounts, and view used and unused voucher information.
Features 🔦
There are 4 features that we plan to implement in this app.
- In-App Barcode/QR Scanner: This feature would allow vendors to scan vouchers for transactions, and automatically update voucher values once a transaction is complete. The admin would be able to view transactions and voucher data owned by vendors.
- Invoice/Transactions: Vendors would be able to view past invoices and transaction history, as well as securely request invoice generation before invoices are finalized. Admins can view vendor invoices and transactions, and update the reimbursement status of vendors.
- User Authentication: Vendors would be able to create vendor accounts so that approved accounts can be used in the app. Admins will be able to create admin accounts, approve vendor accounts, and view all vendor accounts.
- Admin Web Dashboard: This feature is a management dashboard that would address the vendor inquiries and actions mentioned above, and view and update stored voucher data.
One more additional feature that is not included in the scope of the feature (but one we hope to implement if time allows) is push notifications. Vendors will be notified when invoices have been updated; admins will also be able to control notification frequency for vendors.
Tech Stack Overview 🤖
We are working with React Native, Typescript, Expo, and Firebase.
React Native is the framework, Typescript is a type of Java Script, Expo deploys the app on both IOS and Android, and Firebase is the backend that hosts all the data.
To provide a glimpse into how this tech stack came to be, it is important to consider what was needed on the frontend and backend.
The frontend requires native support for different devices, so React Native was chosen given its compatibility between IOS and Android. Blueprint also has a history of working with React Native specifically for frontend development. The backend relays information to the store through vendor invoices. Other tech stacks that we considered were Airtable, and GraphQL.
Technical Challenges 😖
Along the way, we encountered many challenges.
For one, the initial idea for the app was to use QR codes. However, when V4V tried to use the QR codes, their printers would not work. Therefore, we decided to pivot to barcodes, especially because vendors were already a lot more familiar with barcodes. However, the caveat of this change in direction is that barcodes are not the most reliable, leading to many more technical issues. In response, we decided to scan the barcodes with Expo library and Expo scanning!
Secondly, many of the vendors that V4V was working with didn’t have email accounts. Therefore, we had to redesign our sign-ups to make sure that the V4V admin could generate user accounts through email aliases in a secure way so vendors could reset their passwords if they desired. Our solution was to integrate the Firebase API into the Retool dashboard to implement a change password feature so that V4V could manage the accounts.
The last challenge encountered was every voucher serial number included additional metadata that we initially did not know how to handle. To elaborate, each serial number also included information on the date, site, voucher number, page number, voucher range start, voucher range end, month and year of voucher, voucher type, ID, and program and contract that V4V had to physically record. In response, we decided to enlarge the scope of our project, linking all distribution data to an admin dashboard we created using Retool. Now, when admins search up a voucher, they’re able to see all of this information in addition to the transaction.
The challenges mentioned are only a few out of many. However, with each one, we adapted, integrated new skills, and worked together, delivering a mobile app that not only aligns more closely with V4V’s needs, but also exposed us to the reality of working with a fast-paced, real-life organization.
Design 🎨
Behind every developed feature was the careful thought and hard work of our amazing designer, Danielle! Here are a few of the tabs featured on the mobile app.
Next Steps 🤯
As we approach the end of the semester, we are happy to announce that our app is deployed!
However, there are still a few more action items we have to complete. We plan to finish up the Retool dashboard, test it out with V4V, and then see if there’s any errors or other features we can include, adapting accordingly.
Additionally, we plan to split up the dashboard between vendor and admin facing modes. This task requires a staggered roll-out of the mobile app while incrementally testing out each stage with users, collecting feedback and conducting user research to make UI improvements. We will test our three versions, with the first one conducted by us and the rest most likely led by V4V. We also hope to talk to at least 10 users to ensure that the app is genuinely easy to use and navigate.
Key Takeaways 🙌
With every project comes a few takeaways that we’d like to share!
- Understand the Problem: It is oftentimes very easy to be problem-flexible and solution-absolute; that is to say, finding a solution first and then fitting it with the problem. However, we experienced the importance of understanding the problem first through reaching out to the vendors partnered with V4V so we could put ourselves in their shoes and solve problems from their perspective. The solution shouldn’t be what is easiest or more convenient to do, but rather what will actually be used by the NPO. One particular example of this takeaway is exemplified with the ‘Mark Completed’ pop-up that appeared in the center of the screen after a vendor scanned a voucher. However, if vendors had to scan multiple vouchers, they would have to click out of the pop up each time, slowing down the overall process. Initially, the pop-up seemed to do the job of conveying the message; furthermore, it would have been far easier for us to leave the feature as is. In keeping in mind that our ultimate goal for the app was to increase efficiency, our amazing designer changed the pop-up to a notification that would only appear at the top of the screen.
- Communication with the NPO: The NPO came to us with a problem for a reason; they have a much better understanding of the user’s pain points. Therefore, we decided to continuously demo our app and demonstrate user flows so V4V would be able to come up with more ideas on how to modify the app more closely to what the vendors need. Additionally, we set expectations: we made an active effort to make sure V4V understood the scope of our project and what it would be capable of. Although this app would not completely resolve the problem, it optimizes the problem to the best of our ability!
- Help Developers Learn: Throughout the journey of this project, developers felt most empowered when they understood the “why” behind the feature, whether it was why it was designed a specific way or why it is needed. Instead of assigning sprint tasks right away, in the first 2 weeks of the semester, we came together to discuss user flows, so all developers could come up with what they thought would be the best way to solve things. Not only was this process more efficient for ideating and productive for problem solving, but it also inspired all developers to be equally invested in the project, making the work all the more meaningful and rewarding.
My biggest takeaway from this semester was that focusing on team growth is crucial for the success of any project. Being a good PL is not only about levelling up the technical skills of the developers, but also about pushing them to think about building a product that users actually want to use. By involving the team in the process of scoping features and understanding user needs, we were able to bounce ideas off each other and ultimately end up with a better product. — Sauhard (Project Lead, Spring ‘23)
The Team 🥳
alphabetical by first name
Project Leads: Sauhard Jain (Spring ‘23), Noah Hernandez (Fall ‘22)
Designer: Danielle Wong
Developers: Allison Hong, Annie Wang (Fall ‘22), Ethan Auyeung, Selene Huang, Ronnie Beggs
Github
mobile 📲
This article was written by Blueprint external member Sarah Peng. If you have any questions or clarifications, email sarah.peng (at) berkeley.edu.
