I worked for Yumso Inc. after graduated from my undergrad study. Yumso is a Seattle-based startup company that connects home chefs with local food lovers. Yumso provides a platform for people who love cooking and sharing the taste of their home recipe with the community. And with the Yumso app (eater-end), users can order food and enjoy the taste of home which is delivered by our deliver crews.
Within the one year I worked for Yumso, I mainly focused on designing the eater app, and I participated in the transition from version 1.0 to version 2.0.
So how does the Yumso App different from those food delivery apps?
To address this question, instead of looking at the app, let's take a step back to see the dynamic of the environment that Yumso is serving first.
Since home chefs, eaters, and drivers are the most directed stakeholders in Yumso serving system. We started our development process by reaching out and interviewing our potential clients (both home chefs and eaters), as well as our future driver employees in order to understand pursuits and concerns from different aspects. After collecting feedbacks from different stakeholders, I started to organize them into an affinity diagram.
We acquired feedbacks that are valuable for different aspect of our strategy including tech, marketing, product, etc.
Here are some highlights:
Chefs: Chefs on our platform are most likely part-time chefs or people who want but have little experience on running an physical restaurants and therefore choose to open an virtual restaurant at Yumso.
- They worry if there will be times when there are have excessive amount of orders that are over their capacity.
- They want to have a good balance between their life and business.
- They want to be flexible about the menu they are serving.
- They hope they can be informed ahead about the upcoming orders so that they can have enough time to prepare
Drivers: We employ drivers to deliver each order from chefs to eaters; however, we wouldn't be able to hire a lot of drivers due to the budget issue at the early stage.
- They want to be informed ahead about the pick-up time and chefs' location so that they can plan out the most efficient route.
- They worry if they will be able to receive all the take-outs from the chefs at the scheduled pick-up time.
- They also worry that there will be too many order at a time that they can't handle.
Eaters: We interviewed some of our potential eaters who had ordered food online and were interested in ordering food with the "home taste". In general, they have similar expectation to Yumso as to other food delivery apps.
- They want to have various food options from our platform.
- They want to receive their order fast.
- They didn't have previous experience about ordering food from home chefs—there could be potential trust issues.
I found out that "time" and "capacity" is a common and important issue associated with different stakeholders' concerns and desires.
Although eaters are our final customers, whom we dedicate in creating delightful experiences with our service, we also want home chefs (our intermediate client) to success in their business at Yumso. In fact, as Yumso is a home-chef base food service company, it's important that we shape strategies appropriately that specifically address home-chef business instead of regular restaurant business—like all other food delivery services do. How should we optimize our platform for home chefs?
In order to better understand the constrains home chefs are facing, I took a closer look and list out the differences of working environment between regular restaurant chefs and home chefs.
How do home chefs different from regular chefs?
In a restaurant setting, chefs can serve a dish within a relatively short period of time because they might "pre-cook" some portions of the food ahead and cooperating with division of labor can speed up the making process. Therefore, a restaurant can handle a lot of take-out orders at any time as long as it's within its business hours. On other hand, based on the limitations of home chefs that they work with flexible schedules and can only serve limited amount of take-out orders at a day, we need to shape our design in order to suit this situation.
Once we understand the criteria and constrains of home chefs, the whole team started to establish the framework for home chefs' working pattern. On our platform, chefs are allowed to set up their online-restaurant schedules to fit in their life schedule. Besides the Yumso app for eaters, we also developed a chef-end system for home chefs where they can create their shops（online-restaurant), upload their working schedule, and dishes.
On the chef-end system, there are some aspects we needed to consider and coordinate with the eater app:
- Chefs don't have to serve all kind of dishes at every time slot;
- Chefs can open their shops or take a break on any day;
- Chefs decide the business hour they want;
- Chefs supply limited amount of dishes for each time slot/day based on their capacities.
That's being said, different from those regular food delivery apps which people can order any food at any time, at our eater app:
We will arrange menu based on schedules and availabilities.
( and with this model in mind, we are ready to step to the development for our v1.0 Yumso app! )
By the time when I started designing the app, I was told that we really fell behind on our plan. We needed to ship our product as soon as possible. After going over all the requirements with the whole time, we decided to build v1 as a minimum viable product in order to gain feedback for our future product development. Because we were short on time and budget, building a minimum viable product could help us to gain quick and validated learning from users and was cost-efficient. This was not going to be a typical HCD process, where we contributed a lot of time for research and testing at the beginning. At this stage, we aimed to make sure the whole shopping experience worked smoothly.
Collaboration: Ryv Lin (Yumso App v1)
My role: user flow, site map, wireframes
After understanding the appeals of our product in the first few meetings with the team and doing some research on our competitors' products, Ryv and I brainstormed some potential features that we would have. After going over our initial plan with our engineers and talking about the limitations (time / technical restrictions/ budgets), we decide to only keep the most essential features to ensure the shopping flow can run nicely for MVP.
The most important interactive elements during shopping process were 1. choosing a scheduled menu; and 2. choosing quantity and be aware of the availabilities.
Therefore, we created and compared several drafts for individual dish tiles as well as scheduled menu section to see which worked the best.
Wireframe And Interface
v2.0 (trouble shooting and iterations)
Yumso v1.0 served as a good foundation for the development for v2.0 (the completed version of our app!). After v1.0 launched on App Store, we kept iterating to improve user experience and collecting feedbacks from our early users. v2.0 is now on the app store.
My role: usability study, iteration, information architecture, prototype, UI design
1. Menu Schedule
One of the main problems exists is that users are having trouble to locate menu schedules and select a scheduled menu, which is essential for making an order. Different from other food delivery app which deliver food from restaurants that have large food supply and serve a relatively big amount of requests a day, home chefs do not have as limited food supply and can only serve a small amount of request. Therefore, although each shop can serve a variety of dishes, each home chef can set up specific dishes and amount in a selected schedule. As a result, not all the dishes might be available at the time of a day. Users would need to choose a scheduled menu in order to view the available dishes at their desire delivery time.
From our observation and the data we collected, users have a tendency to skip this section (“Out for Delivery” schedule) and scroll over to view the images of menu. Without selecting a schedule, users cannot select a dish and add it to the shopping cart. In v1.1, we iterated by moving the schedule bar to the top at a fixed position; however, this attempt reminded unsuccessful as a lot of users still miss it. And they would have to go back and choose a schedule after the warning message was shown, which was frustrated and not intuitive from a user flow perspective. Further modification was needed.
When observing users on this page, I realized what caused them to skip the menu schedule and scroll over the page was that the less related contents (the images of the shop, shop info, chef page and reviews) were taking too much space at the top when users land on the shop page. Users just quickly scrolled the page in order to see images below, and when they saw the "+/-" they started to choose the quantity; however, they would not be able to select the quantity without choosing a schedule. There was not enough emphasize and instructions for choosing a scheduled menu in v1.
Another issue with v1 is that when there was no schedule available, users weren't able to notice it when looking at the menu pictures (they wouldn't notice it until they tap "Select Time" and see there are no available schedule). There was a feedback I got during an interview:
One day I was looking at the app around lunch time, and I was so excited about a dish. When I tried to choose the quantity, I was prompted to select a schedule, then I realized there were no schedules available that day. What's the point to show me things that I couldn't even order?
I heard similar frustrations during interview, from which I set my design goal for the iteration to be:
- Clearer interfaces;
- A more seamless user flow;
- Refine visual hints and enhance guidance.
Iteration: Sketch, Prototyping
I started by creating different layouts for the top info section and the schedule section, which later were tasted by people:
When observing people interact with my prototypes, I realized that:
- If the full "previewed" menu and the schedule buttons were displayed at the same time, people were more likely to get distracted by the photos on menu, which kept people away from realizing the existence of the schedule section.
- People didn't spend much time on looking upper information section of the shop.
In v2.0, I addressed on the problem I mentioned above and aimed at creating a more instructive interface:
1. Rearranged top sections to save space (yet showing the same amount of information) so that the menu section can be more prominent and obvious at the first glance when landing on the shop page;
2. Users can access to the list of scheduled menus directly without further taps on the shop page;
3. Also provide an option where people can view the full menu that the shop provides.
Information Architecture and Navigation
v2.0 is an expanded version based on v1.0. As it holds more features and its structure should be adaptable for future development, the information architecture should be redesigned in a more reflexible and logical way.
Because the APP started to hold more contents as the information architecture became more complex, the navigation in the APP also needed to update:
In v1, when we only had few features on the app, making the navigation bar as a side bar with a short list of feature options works fine; however, when we upgraded to v2.0, as the features are expanding, a side bar is not adaptable to the many features we have. We should rearrange the features/navigation so that everything can fall in a more organized way. During usability study, I found that other than browse around, "My Order" is a feature that people use a lot. After making orders, users constantly check the status of their orders. As a result, they will need to tap on the hamburger sign in order to access to "My Orders". But tapping an icon on the upper left corner on a big screen phone is not easily reachable with a single hand. Therefore, I realized there's a need to relocate the nav bar and make "Orders" more accessible. Putting the navigation at the bottom is more reachable for most of people.
Yumso v2.0 Interface
What I Learned
I am truly grateful for the opportunity of working at Yumso, where I could start a project from scratch. Although it was a challenge for me to hands on a project , I definitely thrived by being able to fully exposed to different aspects of
Here are some valuable lessons that I've learned from this experience:
1. be able to extract and generate insights from research results
2. set up a scope that we can successfully manage.