Index
- About SnappFood
- Intro to Project
- What’s the Basic Problem?
- We Started to Research
- Problem Statement
- Ideation
- Design Solution and Prototype
- Usability Test
- Success Metrics
About SnappFood
SnappFood is the largest online food & grocery platform in Iran with more than 20M MAU. SnappFood is one of the subsidiaries of Snapp Group which has different products like Snapp (Cab), SnappTrip, SnappDoctor, SnappShop, and…
My Position is the Design Lead of the vendor tribe and the product designer of the Vendor Care squad.
Intro to Project
SnappFood has a service for promoting vendors in the first place on the vendor list. Something similar to Google Ads or exactly like UberEats. Every neighborhood has four shifts for breakfast, lunch, evening, and dinner each day. After creating the ad packages for each neighborhood by the system, vendors try to compete in purchasing packages. Because the package belongs to those who purchased it earlier. There is competition every time that packages are created.
SnappFood has a product called Dakhl. It’s an application for vendors to manage their profile and orders in SnappFood.
What’s the Basic Problem?
This service has been working for 2 years. But atm there is a lot of dissatisfaction that needs care and fixing. Here are some of the basic problems:
- Some vendors can’t purchase the packages. Because they miss the time of package creation.
- We have some packages that can’t be sold.
- Some vendors can’t buy the package from some specific neighborhoods. (because they don’t have access because of our algorithm model)
We Started to Research
To understand the real cause of this dissatisfaction and find a solution to selling more packages, we started to research. I created a survey and a CSAT widget to show after the package purchase process for asking some questions. This helped me to understand the problems of vendors and the difficulty of the process. Also, I created the funnel view of the purchase package in Google Analytics.
Problem Statement
After completing the research process, we found that there are several main problems for vendors:
- Anyone who purchase earlier, get the packages even though there is some vendor that they’re ready to pay more to get the packages (Start of auction and bidding model)
- Insufficient balance after cashout
- Announcement problem for creating packages
- Some logic problems with working hours and delivery area
- and …
and also there were some issues from business:
- Packages from some neighborhoods are never sold
- The revenue from ad packages was not satisfying enough
Ideation
After defining the main problems, we tried to find some solutions by running a few brainstorming seasons.
Anyone who purchases earlier gets the packages. Even though there are some vendors that they’re ready to pay more to get the packages
This problem was interesting for us because we had the idea of the auction for ad packages and this problem was a fact to make sure that it’s a good idea! So I tried to read more about different auction models and understand the economic model of actions. There were several models for each different need. So we discussed these models with the product team, the technical team, and the stakeholders, and finally, we agreed on the “second-price sealed-bid auction” model. We wanted to test fast the MVP version of the auction before getting really involved.
Empty wallet problem after cashout
Let me explain the system first. Vendors can purchase packages only through the wallet of SnappFood. Wallet charges at the end of the day with the amount of sales that vendor has. But the problem is that after every checkout, the wallet of vendors is empty.
Announcement problem for creating packages
There is no certain time for creating packages. Every time packages will be created manually for the next 2 weeks. It means packages will be created biweekly and there is no exact day and hour for vendors to be ready for buy.
Problem with the logic of coverage area
We don’t let vendors be able to buy packages in areas that have lower than 70% coverage between the ad package area and the vendor’s delivery area. But the problem is that some vendors want it and ad packages are worth it to buy even if they can’t cover the whole area.
Design Solution and Prototype
NOTE: SnappFood is a Persian-only application and all of the English designs are made for this study.
Auction Model
We finally designed an auction model for selling the hot and never sold packages. It means for the first version at least, we don’t want to put all of the packages in the bidding system. We only focus on the hot and never sold packages.
These are some benefits of this change:
- Providing an environment for vendors to compete based on the bidding system for fixing the current issue
- Increasing revenue from packages via the bidding system
- Sell the packages which have never sold with a minimum price. There are packages in some neighborhoods that are never sold. We can sell these packages at a fair price with a bidding system. Price will be set by the vendors
Empty wallet problem after cashout
We provided a feature for blocking a fixed amount of money in the wallet. It means that after each cashout, the wallet still has a minimum amount of money for purchases. It can be adjusted by the vendors.
Announcement problem for creating packages
We automated the system of package creation. By now, every day, packages for the next 14 days will be created at a certain time (2 PM). For example, if today is Jan 1st, the packages of Jan 14th will be created today.
Problem with the logic of coverage area
We changed the percentage of coverage from 70% to 40% and also considered a notice banner for areas between 70% to 40% coverage. It means that by now vendors are able to buy packages from these areas but we’re notifying them that it might affect the impact of advertising in these areas.
Usability Test
I made a test scenario for auction to analyze the usability of the design. I had 3 iterations & improvements for achieving the best design. I found some issues in the test like:
- Misunderstanding the timer of the auction
- Solution: Designing different timer views for list and details
- Hard to understand the difference between normal & auction packages
- Solution: Redesigning cards for making them more straightforward and creating a help
- Misunderstanding the “second-price sealed-bid auction” model
- Solution: Provide an example for understanding the auction model
- Confusion about what will happen after placing the bid?
- Solution: Adding a toast after submitting button to show that “If you win, we will notify you via SMS”
- The user expected to see auctions in the basket! We only use the basket for normal packages but they had this expectation to see their auction.
- Solution: Adding a help button in the basket with this title only when the user attended an auction at that session: “Guideline of auction”
- …
These were some UI/UX issues that I found in the usability test and I changed the design for fixing these issues. After applying all of the changes, the result was very satisfying in that vendors could be able to easily understand and use the auction, in comparison with the first time the test. 
Success Metrics
We use Google HEART Framework for measuring the quality and health of vendors’ experience from each part. Here are the metrics of the new discount process:
Note: Base & target were not included
| Goal | Signals | Metrics | |
|---|---|---|---|
| Happiness | It feels like getting a package is very easy and clear | CSATSurvey | Increasing CSATDecreasing unsatisfactory items and issues |
| Engagement | Getting more package Attending more auctionson each session | Number of the purchased packages for each vendor on a session (Metabase)Number of the attended auctions for each vendor on a session (Metabase) | Increasing the number of purchased packagesIncreasing the number of attended auctionson each session |
| Adoption | Onboard and push vendors for getting the first package | Survey (for measuring the onboarding impact)Rate of vendors which purchased at least 1 package from Dakhl in total (Metabase) | Increasing the rate of onboarded vendors from the surveyIncreasing the rate of vendors which purchased at least 1 discount from Dakhl in total |
| Retention | Keep vendors using ads packages | The monthly number of purchase for each vendor (Metabase)The weekly number of purchase for each vendor (Metabase) | Increasing the monthly number of purchases for each vendorIncreasing the weekly rate of discount creation for each vendor |
| Task Success | Make it easy to use for every type of vendors and usage | Track the funnel of purchase in GATrack the funnel of the auction in GAWatching session recordings in YandexRate of purchased/attended packages/auctions from total visitors in GA | Decrease the drop rate of each field and sectionIncrease the rate of purchased/attended packages/auctions from total visitors |
