top of page
Frame 5032.png

A campus-based deal-finder app

Project Type: End-to-end app design & implementation

Role: Research, design, and implementation

Industry: Food

As food prices continue to rise, UIUC students are facing challenges finding quality food within their budget.  Restaurants have weekly deals, but these are advertised in hard-to-find places. This results in missed food deals and specials, where students pay full price for most purchases. 

We decided to tackle this problem by designing and implementing a calendar-based mobile app made exclusively for UIUC students to find daily food deals around campus. 

How It Started

The Brief

Today Only! was created as a semester project for the Computer Science 465 course at the University of Illinois. We were simply asked to find a problem and design a digital product that works as a solution for it. First, we started by narrowing down our problem scope to issues that students face on the Illinois campus. Through browsing popular Reddit posts and reflecting on our own experiences, we discovered that one of the biggest struggles for UIUC students was finding affordable food on campus. 

research_board_long.png

Research Board: Data from the school subreddit, school newspaper articles, food assistance programs

Competitive Analysis

With a well-defined problem in mind, we then analyzed existing solutions to determine whether they fully addressed the issue or if there was a gap in the market. We focused on platforms that share food deals, or supply access to cheaper food. We found that existing options still made it difficult for students to find relevant food deals. Physical signs were only useful if students happened to pass by or enter a restaurant, while online searches required extra effort (such as having to search up individual restaurants) or often led to countless irrelevant deals—many of which were not tailored to college students or the UIUC campus, despite its 60,000 students and 40+ restaurants on Green Street.

Frame 3.png

What do students want?

Before we started prototyping, we wanted to get a better idea of if a campus deal-finder would actually be helpful, and if people would actually use it. We conducted one observational study and two interviews with current students at UIUC in order to answer the following research questions:​

1. What are the needs of the users that would lead them to use this app? 

2. What would deter users from engaging with a campus deal-finder?

Insights to HMWs

Frame 8.png

Constraints

The goal of this project was to design and implement an app that solved a real problem. Our team wanted to deliver a fully functional product by the end of the semester, so we focused on designs with a low network-effect. In other words, we wanted to create something that would be useful to an individual right away, without depending on a large user base or extensive community engagement to have value. With this in mind, we came up with a list of key constraints before we started to brainstorm solutions. The app needed to be:

Implemented by students 

Developed within a one-month timeframe 

Composed of data collected by us

Not completely reliant on user input or engagement

HMWs to Features

Frame 9.png

Our solution idea

A calendar-based app sharing restaurant deals on the UIUC campus. ​​

To keep the project manageable, we limited its scope to Campustown.

A calendar-based structure prioritizes current deals, which aligns with students’ top priority of finding food immediately.

Deals will be collected by the admins, and local businesses can submit deals to the app as well

Using the Google Calendar API would allow us to build the foundation relatively quickly, which frees up time to refine the user experience and incorporate a few additional features.

We chose to prioritize simple tasks navigating around the calendar frame, and focused on quick interactions and deal-spotting rather than developing a social or review platform. 

Ideation

Sitemapping

We began by drawing a sitemap with every anticipated page in our app. The goal for our mini app was for each page to be only a couple clicks away from the home screen. We set our home screen as the current deals screen, as the most likely reason why users are entering the app is to find current deals. We then drew up a rough sketch of our app to visualize its structure. 

Unknown.jpeg

All pages support the app's main goals

2 main flows are 1 click from home page

Home view displays main user goal

Creating Flows

Task Flow

Three main use cases:

  1. Quick Access to Deals

  2. Daily/Weekly Planning

  3. Submitting a deal.

task_flow_miro.png

User Flow

To make this app work for short, quick interactions, we limited the amount of decisions or steps a user would have to take to view a current deal or submit a deal. The app allows for other ways to interact with a deal (reporting, rating, favoriting), and these features are all located close to the home screen. 

user_flow_miro.png

Wireframing

We then drew up a rough sketch of the view deals process so we all understood how the app would be structured.

Frame 4.png

Personas

We conducted five user interviews to determine the needs of the users that would lead them to the app, and the factors that may deter users from engaging with the app. Using these results, we created three non-trivial tasks central to the app that corresponded with the main goals of the users. For each task, we created a persona who would be inclined to do that task, and a corresponding user flow.

Task 01

  • Find a current, close-by deal

  • Know if there is any criteria needed to redeem a deal

Slide 16_9 - 8.png

Iterating based on usability test results

Testing the prototype

We conducted one moderated usability test for each of the three predetermined tasks. Each participant was given a brief description of the persona, and was instructed to complete the corresponding task on the prototype. Interviews were conducted using a contextual interview approach. 


A separate click task was also distributed to seven different participants, asking them to filter by best rated deals, view specials for the following week, and submit a deal to the app. Through this research we determined strengths and pain points of the design. 

balsamiq_prototype.png

Prototype created in Balsamiq

Frame 28.png


Prioritizing changes based on impact and efficiency


We analyzed the findings from the usability tests and plotted them based on the severity that it impacts the product goals, prevelence of the issue, and estimated effort required to resolve the issue.

Frame 29.png

Problem: Unclear deal submission process and little editing ability.

Design Update: User reports feature to address deals which might be invalid or expired, and additional questions on deal submission form to account for repeating deals, varying locations, and hourly-based deals. 

Problem: Confusion between filter and sort buttons.

Design Update: Changing the filter button to a more popular filter icon.

Interface Design


Brand Concept

Our design uses a complementary color palette of the desaturated school colors. Muted oranges and blues relate to UIUC without looking like a university app. A vibrant, fun design works well for our app's short-term interactions, as it improves retention by offering users an engaging experience.

We took inspiration from old advertisement deals, as this app is meant to feel eye-catching, funky, and easy to scan— like a flyer or poster you’d quickly glance at when looking for a deal. Old ad designs typically used bold colors and typography, and a clear visual hierarchy to grab attention fast, which matches our goal of helping students spot the best food deals at a glance. By building on this visual style, we were able to create a design language that balances nostalgia with function, to make deals feel exciting, and immediately accessible.


Deal Card

Before creating hi-fi prototypes, we sent out a survey to 20 participants asking what information about a deal they value most.

The data showed that 70-80% of users care most about:

  • Distance to the restaurant

  • Time window of deal

  • Restaurants/deals ratings. 

The deal card was design to reflect these most desired attributes.

Screenshot 2025-08-18 at 3.58.23 PM.png


Figma Prototypes

The group designed hi-fi prototypes of all screens as a guideline for implementation.

Implementation


Process & Tools

This app was fully implemented in Android Studio.

android_studio_ss2.png

Tools Used:

To find restaurants & deals: Google Places API, Yelp API, personally finding deals on campus from advertisements, friends

For calendar implementation: React-native calendars, Google Calendars API

android_studio_ss1.png


One more round of testing...

Before we submitted our finalized app, we conducted one more round of testing to reduce as much friction as possible and include features that add to the app's experience. With three users' inputs and our own heuristic evaluation, we made the following changes. 

Update: Rate deal + confirmation screen

Before

frame6.png

After

implemented_rate_deal.png
Frame 7.png

Usability Heuristic: Visibility of System Status, Consistency and Standards

A confirmation screen informs users of their action's outcome, and improves confidence that a rating went through.

 

Using a sliding bar to fill in the stars is more intuitive and familiar than our original design of sliding the stars themselves. 


Final Prototype & Reflection

The final prototype of the app allows users to:

  • View current & future deals

  • Save deals to a favorites section

  • Share deals with friends

  • Filter by deal attribute

  • Rate & review deals

  • Submit deals for display

We were able to implement a lot of features central to the apps main goal, and every feature of the app was user tested at least one time. If we had more time, there are still a few bugs that we would like to smooth out (such as the date bar on the week screen not  dynamically adjusting). Other than these minor details, our app is a completely functioning program that my group is very proud of!

bottom of page