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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
We also revisited the Design Principles and from our testing and data realized we were missing an important principle. The new Design Principles are:
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.