Charles Riccardi

Eatsa Mobile

Eatsa Mobile

At eatsa the goal is to bring delicious and healthy food to everyone. The first store was  created with an in-store ordering system, but we knew that soon after launch we would need a mobile presence. So began the journey of building eatsa mobile.

 

Team

1 Designer

1 PM

2 Engineers (front-end, backend)

Research

In order for us to make informed decisions, we needed to understand the current state of things. This required us to gather current data on our in-store ordering system, interview our customers, and research competitor products. This help us define the assumptions, goals, and constraints for the project.

Goals

Customer

  • Order time estimates accurate
  • Eatsa's offering clear and comprehensive
  • In-store order pick up process is clear

Business

  • Scalable design to accommodate future business initiatives (dayparts, extended menu, etc.)
  • 25% of customers a day use the mobile app to order their meal
  • Number of users that download mobile and convert back to kiosk is < 1%

Constraints

  • Operations output threshold

  • Number of cubbies limited during peak times

  • Timeline (1 month for design)

 

 

Home

 Creating a compelling view for home was tough. There were many competitors that had beautiful photography, slick navigation paradigms etc. With the time alloted for the design, we kept it simple intentionally.     1. User testing revealed that there was friction caused up front by biasing users with photography in the navigation (#1). If the item didn't look like something they would enjoy, they could churn too early.     2. Having no photography made the experience feel stale (#3), and compared to other products, it severely lacked the appetite appeal.     3. Because the location selector was presented during onboarding, it wasn't clear during the ordering process where a user was ordering from.     4. The vocabulary used in the navigation list made the type of offering clear.      

Creating a compelling view for home was tough. There were many competitors that had beautiful photography, slick navigation paradigms etc. With the time alloted for the design, we kept it simple intentionally.

 

1. User testing revealed that there was friction caused up front by biasing users with photography in the navigation (#1). If the item didn't look like something they would enjoy, they could churn too early.

 

2. Having no photography made the experience feel stale (#3), and compared to other products, it severely lacked the appetite appeal.

 

3. Because the location selector was presented during onboarding, it wasn't clear during the ordering process where a user was ordering from.

 

4. The vocabulary used in the navigation list made the type of offering clear.

 

 

 1. We were able to keep the location at the center of this view by borrowing what other apps had done really well.     2. Removing the hamburger menu reduced unnecessary processing and made this view the "home base" for navigation.     3. Keeping order history in the view at all times created a good signal for users who had dined with us prior. When the item was tapped, it would prompt for the users log in credentials. Previously we would use progressive disclosure and add the nav item once they logged in.      

1. We were able to keep the location at the center of this view by borrowing what other apps had done really well.

 

2. Removing the hamburger menu reduced unnecessary processing and made this view the "home base" for navigation.

 

3. Keeping order history in the view at all times created a good signal for users who had dined with us prior. When the item was tapped, it would prompt for the users log in credentials. Previously we would use progressive disclosure and add the nav item once they logged in.

 

 

(No) Onboarding

 We wanted customers to get into the app super fast, so they were presented with the menu quickly.     1. We started off testing a landing view (#1)&nbsp;where the main call to action was to see the menu. Although this was headed in the right direction, we challenged ourselves to make this transition even easier.      

We wanted customers to get into the app super fast, so they were presented with the menu quickly.

 

1. We started off testing a landing view (#1) where the main call to action was to see the menu. Although this was headed in the right direction, we challenged ourselves to make this transition even easier.

 

 

So we asked ourselves "why do they need to decide anything in the beginning? By removing the options up front and surfacing the menu immediately we could make the experience much more fluid, especially for new customers.

 

1. Current Customers — To give current customers access to their data they could tap on either the account icon in the top bar or "order history" in the main navigation. This would prompt them for their log in credentials.

 

2. Location Services — If a user chose not to give us their location, the experience degraded gracefully and presented them with an unordered list of whatever stores were available.

 

Ordering Times

 When it came to ordering times, we tried testing out time ranges first. This was easier for the operations and engineering teams to implement due to their constraints.     1. Users lacked confidence in the accuracy of the range (#1-3). They were more sensative to the concept because they were picking up the order themselves rather than it being delivered.     2. Time slots introduced cognitive load, and didn't add any additional value.     3. There was still a disconnect between placing an order now vs. later.      

When it came to ordering times, we tried testing out time ranges first. This was easier for the operations and engineering teams to implement due to their constraints.

 

1. Users lacked confidence in the accuracy of the range (#1-3). They were more sensative to the concept because they were picking up the order themselves rather than it being delivered.

 

2. Time slots introduced cognitive load, and didn't add any additional value.

 

3. There was still a disconnect between placing an order now vs. later.

 

 

 Next we tried out single times.     1. Users felt this was much clearer. They also had a default buffer of 2-5 minutes.     2. Because the concept was simplified, we tested a wacky design (#1). It turned out to be too noisy and felt very disorganized.     3. The amount of information displayed in the view still needed to be reduced.      

Next we tried out single times.

 

1. Users felt this was much clearer. They also had a default buffer of 2-5 minutes.

 

2. Because the concept was simplified, we tested a wacky design (#1). It turned out to be too noisy and felt very disorganized.

 

3. The amount of information displayed in the view still needed to be reduced.

 

 

A prototype we tested that lead to the discovery of the users default (2-5 minute) buffer. People were generally fine with the time changing within 5 minutes of the actual time they chose.

 
 This is the design we landed on.     1. The relationship between place now and the scheduled times was much tighter due to the visual similarities.     2. We significantly reduced the amount of information in the view and allowed the users to fill in the blanks where needed (aka give your users more credit).      Things I would have changed:      • Better design/messaging when the "place now" feature wasn't available.     • I would have tested scheduled times only (no "place now" feature). It's possible we could help form habits that increase both customer and business value. Customers would schedule orders ahead (set it and forget it), and more committed orders for the business.

This is the design we landed on.

 

1. The relationship between place now and the scheduled times was much tighter due to the visual similarities.

 

2. We significantly reduced the amount of information in the view and allowed the users to fill in the blanks where needed (aka give your users more credit).

 

Things I would have changed:

 

• Better design/messaging when the "place now" feature wasn't available.

 

• I would have tested scheduled times only (no "place now" feature). It's possible we could help form habits that increase both customer and business value. Customers would schedule orders ahead (set it and forget it), and more committed orders for the business.

Menu Details

 Menu item lists were really great to test because we quickly found that most customers wanted the same information at the top level before diving into the item detail view. This also helped us focus the food around being healthy.     1. The team and I thought that having the buttons present for every item would be a bit overwhelming, but it actually ended up creating a good signal that our food items werre customizeable (which many users were a fan of).     2. Seeing menu descriptions was not as useful as the seeing the ingredients.     3. It was important for users to see other nutrition info before diving too deep. Our assumption was that calories, protein, and whether the item was served warm or cold were the best signals for making a decision.     4. Nutritional icons were distracting and weren’t needed. Once the user learned what was there, they could easily scan each item while scrolling.      

Menu item lists were really great to test because we quickly found that most customers wanted the same information at the top level before diving into the item detail view. This also helped us focus the food around being healthy.

 

1. The team and I thought that having the buttons present for every item would be a bit overwhelming, but it actually ended up creating a good signal that our food items werre customizeable (which many users were a fan of).

 

2. Seeing menu descriptions was not as useful as the seeing the ingredients.

 

3. It was important for users to see other nutrition info before diving too deep. Our assumption was that calories, protein, and whether the item was served warm or cold were the best signals for making a decision.

 

4. Nutritional icons were distracting and weren’t needed. Once the user learned what was there, they could easily scan each item while scrolling.

 

 

  Things I would have changed:      • Larger photography to help create more appetite appeal.     • Filters based on dietary preferences

Things I would have changed:

 

• Larger photography to help create more appetite appeal.

 

• Filters based on dietary preferences

In-Store Experience

 We tried a range of different communications to help aid the customer in a fluid transition to the physical store.     1. Too much information (i.e. illustrations and text) would overwhelm and create a more confusing experience than needed.     2. Simplifying messages but creating too many steps was still too much. We created an illusion that our store experience was complicated when in fact, it wasn’t.     3. Tested real photography, etc. but when tested many users thought that was the bowl they were getting.      

We tried a range of different communications to help aid the customer in a fluid transition to the physical store.

 

1. Too much information (i.e. illustrations and text) would overwhelm and create a more confusing experience than needed.

 

2. Simplifying messages but creating too many steps was still too much. We created an illusion that our store experience was complicated when in fact, it wasn’t.

 

3. Tested real photography, etc. but when tested many users thought that was the bowl they were getting.

 

 

 
  Things I would have changed:      • Made it feel more lightweight by "combining" the order status view and this one     • Used a video for better education      

Things I would have changed:

 

• Made it feel more lightweight by "combining" the order status view and this one

 

• Used a video for better education

 

 

Main Project Challenges

• Different people think "healthy" means different things. Balancing what to show and where was difficult because it didn't feel like there was one right answer.

 

• Ordering times were tough from a logic perspective. The back-end engineer and I sat down for many hours to go through user experience ideals, back-of-house procedures, and engineering logic to connect all the pieces together.

 

• Creating an experience that would feel really great now, but also scale for the future (i.e. day-parts, daily specials, weird menu situations where different stores would have different menus, etc.)