When asking home chefs about their concerns, most of the concern and desire were related to time and capacity:

1. a good balance between life and business: flexible working hours

2. worry if they can’t handle excessive amount of order all at once

3. selected dishes based on the time of the day

Design Problem

///

Although the targeting users of the app are the eaters,

how should I shape my design in the app to align it to home chef’s working pattern? 

Solution

Based on the limitations of home chefs that they need flexible business schedule and can only serve limited amount of take-out orders at a day, we decided that at Yumso:

• 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.

In order to reflect these values back to our eater app, we decided to set “time” as part of the criteria during the ordering process because restaurants might have different business hours and supply different menu at different time.

Challenge

People are not used to this mental model / user flow

With the previous experience that people had with other food delivery apps, they expected that after entering an online restaurant, they would be able to view the menu and order food. When we introduce one more step (choose a time slot to view the menu) into the ordering process, people might have difficulty adapting to the new step. We needed to build up v1.0 quickly in order to test whether our approach works or not.

We were trying enforce the idea that after people choose a restaurant on the home page, then they will need to choose a time slot in order to view the scheduled menu:

After comparing the pro and con among the option, we decided to enforce the idea that after people choose a restaurant on the home page, then they will need to choose a time slot in order to view the scheduled menu:

v1.0（MVP)

Due to the constrains we were facing, we decide to make our v1.0 as MVP.

Constrains:

• Short on time for design and testing;

• Short on budget;

• Had only two part-time engineers;

• V1 needed to be shipped as soon as possible.

Some Process

Feature & Sitemap

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.

Sketches：Interactive Elements

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

Result

We ran Version 1 for 3 months to collect user feedbacks. During the time we also do mini updates to see if it fix some usability issue. Overall, Version 1 served as a good foundation for the development for v2.0 (the completed version of our app!).

v2.0 (trouble shooting and iterations)

 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. 

Problem

Pain Point: What happened in V1?

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 because users would need to choose a scheduled menu in order to view the available dishes at their desire delivery time.

Trouble Shooting: Why that Happened?

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.

Usability Study

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). 

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:

1. Clearer interfaces;

2. A more seamless user flow;

3. Refine visual hints and enhance guidance.

Iteration

Paper Prototyping and Testing

I started by creating different layouts for the top info section and the schedule section, which later were tested with participants:

Findings

When observing people interact with my prototypes, I realized that:

1. 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.

2. People didn't spend much time on looking upper information section of the shop.

Hi-fi Prototype

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.

Prepare for future development

Refine 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

Interactive Prototype