ZIPLUNCH

Case Study

Project Information

Company

Ziplunch

Team

Flatiron

Timeline

1 Month

Role

UX Designer

Website

About the Subject

Product Details

ZipLunch primarily provides business or commercial building renters and tenants to order lunch and dinner from local restaurants at takeout prices with free delivery. ZipLunch is now expanding to provide their services to condos and apartment buildings during the time of quarantine.

Client Business & Product Goals

The business wants to scale their offerings to condos and apartments and in doing so provide a comprehensive ‘restaurant dashboard/portal’ where a restaurant owner (user) can sign up and create an account in order to: upload and set up menu items, set prices, establish schedules, manage deliveries and orders, process payments and adjust account settings. Some of the menu and pricing settings are subject to Ziplunch approval prior to going live.

Challenges and Objectives

Challenges

Currently, Ziplunch is manually placing orders with the restaurants after receiving them from their customers and that is not scalable. It is hard to maintain current processes and an automated solution is needed. By providing the restaurant owners with their own administrative system or portal, bulk orders can be placed and fulfilled with ease and in return, this will likely help with new restaurant sign ups and reduce restaurant turn over.

Objectives

  • Improved user experience

  • Increased conversation and orders

  • Provide tools to allow restaurant owners and their staff to manage their menus and orders with Ziplunch

Where To Start? (Empathize)
Click to Expand

Exploratory Research

To get started, I did some exploratory research where I broke down:

  • Who are the lead competitors in the marketspace?

  • What are the trendsin the marketspace?

  • What are the opportunitiesin the marketspace?

  • Who is the target audience for this platorm?

  • Any Data about the marketspace.

Click to Expand

Competitive Analysis

What I did next was a competitive analysis to see:

  • Where the current market is and is going?

  • Who are Ziplunch sharing the marketspace with?

  • What makes each company in the shared marketspace different?

  • Where can my client position themselves in the shared marketspace to set themselves appart?

  • What are some of the key features that the competition is doing?

Interviews

Once I figured out who our competitors were and where Ziplunch needed to be in the marketspace, the team collectively wrote out interview questions and a script to interview SMEs (subject matter experts) and potential users. We found that this project is a little unique in the aspect that our SMEs are also our potential users.

Since my team and I are confined to our homes because of Covid-19 we conducted interviews over Zoom and through our phones which were recorded and later transcribed. This method has some positives but also presented some negatives.

Positives

  • Less formal and more relaxed for the interviewee because they are in a familiar atmosphere

  • Since it was more relaxed, I feel I got more genuine answers to our questions

  • No travel time for the interviewees because they were able to use their phone or PC to do the interview.

Negatives

  • Most interviewees either canceled last minute or did not show up. I feel this was because it was such a relaxed interview

  • Of the interviewees that did show up, all of them did not have their cameras on which did not allow to see their body language when answering questions.

What Was Discovered? (Define)
Click to Expand

Persona

After taking in all the demographic information from our interviews and research, we were able to build a user persona of the ideal user that would be working with our portal. This will allow us to concentrate on building the portal for this specific user but will encompass the overwhelming majority of the users.

Click to Expand

Problem Statement

Taking into account the qualitative data we received from our interviews and research, we were able to arrive at multiple problem statements that we combined into one statement.

Design Principles

The Design Principles were taken from the qualitative data from the interviews. These principles are what we used in the design process of the portal.

Click to Expand

Extra Info

Some interesting information came to light during the meetings we had with the client each week. During the meetings we found out: 

  • Ziplunch is an aggregate delivery platform. Meaning that they deliver multiple meals to a hub drop off for individual people.

  • The delivery portion of the food ordering experience is the responsibility of the restaurant instead of 3rd party delivery drivers

Conflict With Research

Most of the competitors the client gave us and the ones we found during the competitive analysis offered delivery through either their own company drivers (uber eats) or through 3rd party delivery drivers (doordash). The fact that Ziplunch does not offer a delivery service through their company or through a third party could hinder their growth later on. This was mentioned multiple times throughout the second meeting when we were discussing the competitive analysis and was also discussed during the future recommendations portion of the final hand off. Since this had little to do with what we were tasked to accomplish we moved on to designing and creating the restaurant portal.

Is It Time To Design? (Ideate)

Divergent 6-8-5

During the 6-8-5 sketches I was trying to layout what the portal dashboard might look like and what some of the functions (create a menu, processing and order) might look like. I am not that great of a drawer but I did sketch on paper my ideas for the quick aspect of the 6-8-5. I then transferred them to a sketch-like layout in Figma for better comprehension.

Divergent Low Fidelity

Once the group described each of our divergent concepts we refined our drawings to show and look better for testing purposes. Each of us tested individual users on our divergent low fidelity wire-frames to see if the flow of the portal was user friendly. We took the loose style interviews and brought in the recommendations to each other to complete the convergent mid fidelity wire-frames.

Wire-framing Kit

We needed to agree on a wire-frame kit to use so that all of our converged designs looked coherent. We searched online for a kit and found one that we all agreed upon and started building out each section of the portal that we were responsible for.

Convergent Mid Fidelity Wire-Framing

Before jumping in to design the mid fidelity wire-frames we “Zoomed” and shared notes on what the low fidelity prototyping recommendations were from our interviewees, looked over the requirements set by our clients, and laid out each section accordingly.

I was in charge of laying out the dashboard and helping with all the other sections when needed. I ended up laying out the restaurant and menu schedule as well as helping out with the on-boarding for the portal.

Convergent Mid Fidelity Prototyping

We were given the task to allow restaurants the ability to manage their orders and menus through Ziplunch. What we ended up giving them was the ability to:

  • Control the on-boarding process

  • Manage their restaurant schedule

  • Manually add items to the menu

  • Upload the menu as a pdf (depending on coding)

  • Live tutorial once landing on dashboard

  • Allow the kitchen to control the order process

  • Able to check on an order

How Did The Testing Go? (Testing and Reiterate)

Testing

Their were ten participants scheduled for testing but the team ended up only being able to test seven because of cancellations and scheduling conflicts.

The participants were all people who, at one point in their lives, had worked in the food industry. The testing document we gave them had vague instructions on how to complete certain tasks. We timed and recorded each person and calculated the results to show the client how easy the portal is to use and the functionality of what we were delivering.

Results

The results were calculated in a google sheets document. Every person’s time on each task was recorded and written down as well as miss clicks and times stuck for quantitative results.

At the end of testing, we asked  each participant to rate each section of the app on a scale of 1 to 10 and also explain why they rated that section how they did. These qualitative and quantitative results were used to show where areas of improvement could be had in the portal as well as what areas the users had no issues with.

Reiteration of Problem Statement

The problem statement is a living/breathing document and can change at any time. After going through the results from our mid fidelity testing, we noticed that there were a couple of things that we needed to address in the problem statement. We went through and changed it to:

The restaurant owner wants a clean, simple, and portable administrative tool with a supportive on boarding process that allows them to manage their menu, schedule as well as their order process so that they are better able to reach a larger market, efficiently meet these customer needs, and maintain productivity.

Reiteration of Design Principles

We also revisited the Design Principles and from our testing and data realized we were missing an important principle. The new Design Principles are:

  • Organized – Access to all data relative to your business in one place

  • Reliable – Change is good, but consistency is key.

  • Convenient – Spend a minimal amount of time finding what you need. 

  • Simple – Prioritize ease of use in platform

  • Portable – Take the controls with you no matter where you are going

The End, Or Is It?

Future Recommendations

Top Navigation
Uploading a PDF
Ordering Section Process
Order Status Page
Menu Schedule
Delivery Drivers

Most of the test takers said that they did not realize in each section that the top portion was a navigation. So, we need more emphasis that the top is usable navigation. Maybe in the high fidelity wireframes we add color to the text or a different color background.

Client needs to talk with developers and see if uploading a pdf and having it take the info into a workable layout is an option. If pricing and timing does not fit the scope of the project, we could have the submission go to a Ziplunch representative to input the information in manaually.

The restaurant owner/manager users we tested said that it is too many taps/clicks for the kitchen to control and another way to have less taps or clicks is needed.

Ziplunch, on the other hand, was very pleased with the ordering section process. We voiced to the client that the users were displeased with the amount of taps/clicks the user would have to do.

A simple way to change the order status from not delivered to delivered is needed. The options we offered were:

1. Have a message go to customers once the order leaves the restaurant and 30 minutes later ask the customer if they received their meal. Once 1 customer says yes the order changes to delivered.

2. Have the restaurant driver select that the food has been delivered from his phone or call in to the restaurant to have them change it to delivered. Once that happens the customers get an email saying the food has been delivered to the hub in there building.

3. Have a GPS signal in the delivery car and once the driver is within 50 feet of the hub send an email to the customer saying their food has been delivered and change the not delivered to delivered in the Ziplunch portal.

One problem we had while testing was why does the menu schedule live in schedule instead of menu. The options for this would be:

1. Move menu scheduling to the menu section

2. Leave menu scheduling in the schedule section

3. Put it in both the menu section and the schedule section

This was once again brought up to us multiple times during the interview and testing phases. The restaurants do not like having to hire people specifically to deliver or even take the time to deliver the food themselves. With the boom of online ordering and delivery services, most restaurants in Toronto have leaned toward having the online services be the delivery people.