Eatery is a nutrition focused dining platform. It is primarily a mobile app where users are provided a way to discover, intelligently choose and track what they consume while eating out. With the help of the UCI Informatics Capstone team now Eatery can provide a way for small restaurant owners to share their menus, provide nutritional estimates to their customers and track mobile app user engagement.
Kyle Sanders
A mobile app that helps users find restaurant menu items that fit their nutritional needs and budget.
Eatery currently is only able to provide menu and nutritional information from large chain restaurants. Small restaurants want to provide accurate nutritional information but it’s expensive, time-consuming, and hard to keep up with menu changes.
01 Gather feedback and research from interviews and user stories.
02 Meet frequently with partner to constantly iterate and improve our product.
03 Started with features that were most essential and not overly time consuming to implement.
Each week, we met with our project partner, Kyle Sanders, to align on the product vision, gather feedback, and clarify next steps. Without a dev team on his end, we often had to dig deeper by asking the right questions to turn broad ideas into concrete features. Over time, we learned to balance his big-picture thinking with realistic timelines to keep things moving. Instead of giving us tasks, Kyle gave us ownership. That freedom pushed us to lead, think independently, and truly take charge of the product, something our team really valued.
Goal with interviews:
We wanted to learn about the daily routines, the challenges faced in the kitchen, opinions on nutritional transparency, and how restaurant owners currently handle customer questions or menu changes, however we were met with a challenge...
Initially it was hard to find restaurant owners because they're busy, don't always check email, and often don't trust unsolicited outreach.
We improvised by finding other people in the restaurant business such as managers and line chefs.
Talking to people who had more exposure to customers gave us more insight into customer needs, what questions they ask when they order food, and how their decisions are influenced by nutritional information.
We learned that the process to get user research and pain points is not going to be perfect but getting the conversation started with anyone in the industry is important. For example, we didn’t think the interview with the line chef would benefit us that much but we actually learned the most about what customers request and another valuable insight about how menus constantly change which adds to the difficulty of managing their menus.
After interviewing 8 people across food operations, including chefs, managers, waiters, and restaurant owners, we learned the challenge in sharing nutrition information is:
Changing prep methods.
Fear of exposing proprietary recipes.
Limitations of existing tools like POS systems that aren’t built for nutrition.
“People always ask if something’s gluten-free or what’s in our sauces, but we can’t just hand out our recipes.”
-Restaurant manager, Los Angeles
From these insights, we developed personas that reflect the real-world struggles of people in the food industry, those who prepare the meals and those who manage the business behind them.
After speaking with different restaurant owners, we began to notice common needs and these insights helped shape the three key requirements we prioritized in our solution.
Simple onboarding process for non-technical staff.
Fast turnaround for testing live menus.
A scalable way to upload and calculate nutrition info.
With these requirements in mind, we focused our solution on two core features that directly address what users need most.
Addresses non-technical onboarding
Supports users who want fast, accurate nutrition info
Once we identified the most urgent user needs and stakeholder priorities, we translated those into clear product decisions that would guide our MVP build.
"It's hard to track every ingredient, prep changes every day"
We implemented an AI that populates ingredients and macro count based on the name of the dish.
"We don't want to give away our recipes."
We let them tag dishes with just allergy and macro info, no full ingredient list needed.
"We already use a POS system, don’t make us learn something new."
We built a simple step-by-step flow for uploading menu items that feels like their POS setup.
Designers sketched out our vision and annotated the flow to help stakeholders visualize how the AI-powered upload would work.
↓
We received targeted feedback early on that helped us simplify interactions and reduce confusion around ingredient entry.
We turned our sketches into a Low/Mid-Fidelity using Figma to better visualize layout and information flow.
↓
There was confusion about how ingredients would auto-populate, and didn't notice the optional fields. This feedback helped us adjust the hierarchy and layout, making the AI features more visible.
We upgraded to a high-fidelity mockup, focusing on visual hierarchy and real menu examples to better simulate how users would interact with the AI-powered upload.
↓
Users didn't know where to click next. The layout felt too compact, and steps weren't clearly guided. We understood that the layout needs to be step-by-step with spaced out key actions to guide users through the upload process more clearly.
After conducting user testing we learned that it was hard for our stakeholders to know where to begin and what to do next. The layout was too dense, and users didn’t realize certain fields were optional.
We simplified the experience into a step-by-step flow, breaking actions into smaller chunks to guide users more clearly and reduce cognitive load.
Hard to see what the next step is.
The step-by-step layout gives users more confidence that they're successfully completing that step.
Adding an image is optional, but giving it its own step makes the experience feel more complete. The drag-and-drop interaction also makes uploading easier and more intuitive.
We included a progress bar because psychology research shows that visible progress encourages users to complete a task. It's included to reduce users from becoming overwhelmed (Endowed Progress Effect, Nunes & Drèze, 2006).
We ran an A/B test to see which version actually helped users navigate the flow more confidently.
Version A
Version B
We conducted user testing as well as A/B testing to test our product and evaluate it. From the user testing we got good feedback on how intuitive our design was and how we can improve it. We then used A/B testing to further understand which changes were better and overall help us choose the best design choice. Overall we found the second design was easier for users to understand due to less clutter and a more streamlined process
After gathering requirements and discussing the goals with our sponsor we crafted some initial sketches and wire-frames to guide our vision.
We stepped further into this design creating some Lo Fi designs that we could test and further discuss before crafting the final prototype.
With the Hi Fi prototype completed our development team had a goal to start building towards!
Our Jira board housed our tasks and helped us stay organized while navigating our project. We stored all our user stories as well as various tasks that we had to complete. Once we switched to 1 week sprints we reorganized the board and broke it down into smaller tasks.
We used Figma to create all our designs from wireframes to high fidelity mockups. Figma was essential for our implementation as it guided design choices and allowed us to see iteration of our design.
We used firebase as our backend to store restaurant data, menu items, and owner accounts.
Our GitHub helped keep our code organized and was our version control of choice.
After talking with potential users of this application, they all had data and analytics at the forefront of importance. For this reason, we designed the dashboard to have a high-level overview of these analyitics that a owner would need to continue running their business, while providing value to their operations. This includes the amount of dishes they sell in a week, types of protiens are selling in comparison with others, and total customer growth due to this application.
Our Menu Items page displays the list of dishes the user has uploaded onto their restaurant page. As you can see, users are able to add new items or edit previously added dishes with new ingredients or serving sizes.
Our team wanted to ensure a seemless process for a restaurant owner to upload information about their dishes such that a customer would be better informed about the foods they eat. This panel allows owners the freedom to insert and update their dishes quickly whenever necessary.
Demo Day! 🥳
"Software development is unpredictable and that the documented artifacts such as specifications and requirements will never be fully understood."
-Professor Ziv
As a group, throughout the past 6 months, we've internalized this law deeply. The group all carried their own individual experiences throughout this project however we all came away with the realization that software is inherently difficult to predict and design.
Web Scraper - In our project description we were tasked with first developing a large scale web scraper. This proved to be challenging in many ways and primarily we were limited by resource and systems design limitations.
Pivot to Web Application - This challenge lead to to pivot to the second portion of the project which was building a web application for restaurant owners to share their menu items, get estimates and join the Eatery ecosystem.
Difficulty in sourcing interviewees - Getting a hold of restaurant owners was difficult and this taught us to improvise by getting the conversation started with anyone in the food industry. We didn't want cookie cutter answers, we wanted insights.
It was my first time working with a group of devs so I learned a lot of communication skills and you never really know how a product will turn out until the designer and devs build it together.
-Thanusree
Getting the whole team working together on a single problem is difficult to achieve but it’s the most effective at solving the right problem the right way. We found our greatest successes when we hit this balance and were all able to push towards a common goal.
-Matt
This was the first project I worked on that involves so many different moving parts and features. I learned a great deal about the Software Development process and how much planning it requires to produce a usable product.
-Quincy
Working with a new team on a startup-like project was quite eye-opening on just how challenging the process can be. Through late nights, we learned a great deal about new technologies and software processes. As a team we stepped out of our comfort zones to produce a complete solution to the problem, and that's something we're proud of.
-Jefferson
This was my first Capstone project and it was big learning curve for me. As a group, we learned how to pivot and tackle challenges. I learned a lot about designing a full website while developers are also trying to implement the best architecture. I also learned that there's numerous solution to one problem and numerous problems to one solution.
-Jennifer
This was my first major project working in big team so that I learned a lot from the experience. Besides the technical skills, I developed my communication, organization, and public speaking skills.
-Hung
Design and carry out more user testing - As a group we're proud of what we've put together, however we all feel that with some feedback from the web app's target user
Connect the Eatery Web Portal with the Mobile App - Our work was aimed at providing a service for small restaurant owners to gain nutritional information, share and gain customers for their menu offerings.
Continue to explore ways to engage small restaurants and health conscious restaurant patrons - As stated several times over our project goal is to cater to the needs of small restaurants and help them provide their customers with accurate, accessible and up to date nutritional information.