Repository navigation
MS4
Problem: University students looking for food near campus have no centralized or current source showing what establishments are offering to eat today. Menus and prices change daily, but this information isn't captured by Google Maps, generic reviews, or word of mouth — by the time a student needs it, it's either outdated or simply missing.
Solution: Daily menu feed, a shared mobile feed where establishments near campus publish their current daily menu — dish, approximate price, publication time, and location — so students can compare available alternatives in one place. Its main smart component compares the post's timestamp against the current date and time to automatically hide or flag expired menus, and students can report changes to keep the feed accurate throughout the day.
PAS 1
- Problem: A menu post can become inaccurate during the day even before it expires — an item sells out or the price changes, but the post still shows as valid.
- Alternative: (a) rely only on the automatic time-based expiration; (b) let students flag a specific item as unavailable; (c) require establishments to manually update the post in real time.
- Solution: Add a quick "this item is no longer available" report option for students, which lowers the post's visibility before its full expiration window ends.
PAS 2
- Problem: An establishment may forget or delay posting its daily menu, leaving a silent gap that looks the same as "nothing to eat here today" to students browsing the feed.
- Alternative: (a) do nothing and let the gap go unnoticed; (b) send the establishment a daily reminder to post; (c) show an explicit "no menu posted today" state instead of just an empty listing.
- Solution: Send a consistent daily reminder notification to registered establishments each morning, and mark unposted venues explicitly instead of leaving them blank.
PAS 3
- Problem: A student can pick the right establishment from the feed and still lose break time locating it on arrival. Many of these venues are small, unfamiliar to students who have not been there before, and clustered close together with little or no signage, so identifying the correct one among several neighboring options is not obvious. Students in their first semesters carry the most of this cost, since they have the least accumulated knowledge of the area.
- Alternative: Rely on the address text and an external map application; let students who have already visited submit a short description or photo of how to identify the place, require a storefront photo and verified pin as a mandatory field at registration, or make the photo optional but surface it as a completeness signal on the listing.
- Solution: Make the storefront photo and verified location optional at registration, but display listing completeness on the feed so that publications without them appear visibly weaker, and show both next to the menu publication when present. This lets the student see what they are looking for before leaving, without blocking small establishments from onboarding.
PAS 4
- Problem: Establishments post their daily menu without any way to tell whether it reached students or influenced anyone's decision. Posting takes effort every morning and returns nothing observable, so a venue that sees no visible result has little reason to keep doing it. This is a retention problem on the supply side: a feed with fewer active publishers is worth less to students, which in turn reduces the traffic that would justify posting.
- Alternative: Leave the establishment with no feedback and rely on daily reminders alone; send a periodic summary by email or message outside the app, or give the establishment a simple in-app view of how its recent publications performed.
- Solution: Provide establishments with a minimal performance view showing how many students saw each publication, how many opened it, and how many confirmed arrival, so that posting produces visible evidence of reach rather than only effort.
PAS 5
- Problem: Students with short breaks need to identify a food option that simultaneously fits their budget, available time, location, and dietary requirements. However, this information is currently scattered across friends, social media, generic reviews, and physical exploration, making comparison slow and uncertain.
- Alternatives: Students currently ask friends for recommendations, search across Google reviews or social media, walk between establishments to compare options in person, or return to a familiar place when the search requires too much time and effort.
- Solution: Provide a relevance-ordered view of today's valid menu publications. The feed filters out expired posts and ranks the remaining alternatives according to the student's selected budget, dietary requirements, current location, and available minutes. Each result explains which constraints it satisfies.
PAS 6
- Problem: Knowing today's menu and price is not enough for students with limited breaks because the publication does not indicate the current queue or expected service time. A student may select an apparently suitable establishment, walk there, find a long line, and lose a significant part of the available break.
- Alternatives: Students currently walk to the establishment to inspect the line, ask friends whether the place is crowded, abandon the establishment after arriving, or choose whatever alternative is already on the way to their next class.
- Solution: Add a crowd-updated waiting-time indicator to each current menu publication. The estimate uses recent student reports and historical reports from the same time of day, while older reports automatically lose relevance so that the displayed estimate reflects current conditions.
PAS 7
- Problem: Establishments write their menu as free text, so the same dish or dietary condition gets written differently from one post to the next. Interview participants said they think about food type and price before trying somewhere new, and one asked directly for a list of places with approximate prices, but free text makes that kind of comparison hard to build.
- Alternative: Leave menus as free text and let students read and compare each post by hand, or guess structure from the text after it's posted, using keyword matching, or ask establishments to fill in a short form with fixed fields before the post goes live.
- Solution: A structured posting form for establishments, with required fields for category, price range, and dietary tags, so every post in the feed can actually be filtered and compared instead of just read one by one.
PAS 8
- Problem: Before trying somewhere new, students look for signs it'll be worth it. Interview participants described checking Google reviews, TikTok, and comments, or relying only on what a friend has told them. A new establishment on the daily menu feed starts with none of that, so a good post can still get skipped simply because nobody has vouched for it yet.
- Alternative: Give no trust signal at all and let students build confidence through trial and error, or have a moderation team check each post before it goes live, or let students confirm after their visit whether the post matched what they found, and turn that into a visible score.
- Solution: Add a simple accuracy score to each establishment, built from how often recent visitors confirm a post matched reality, so new or unknown places on the feed carry some of the reassurance a friend's recommendation gives today.
PAS 9
- Problem: The feed is needed exactly where and when the phone works worst. Students check it while walking out of a building around midday, when the campus network is saturated and the device may switch to mobile data. If the request fails or takes too long, the student loses the window and falls back to the usual place, which is the behavior the feed exists to replace.
- Alternative: (a) keep the feed online-only and show a spinner or an error when the request fails; (b) retry silently in the background until the network recovers; (c) keep the last successfully loaded feed on the device and serve it while the connection is unavailable.
- Solution: Store the last loaded feed locally and display it immediately when the network fails, labeled with the time it was retrieved and with publications already past their expiration hidden. The student sees something usable instead of a blank screen, and always knows how old what he is reading is.
PAS 10
- Problem: Many small establishments near campus accept only cash or a single transfer app, and that is not part of the publication. A student can choose correctly on dish, price and distance, walk there, and be unable to pay, losing the same break the feed was supposed to protect.
- Alternative: (a) leave it out and let the student ask on arrival; (b) let students report the accepted payment methods after visiting; (c) make accepted payment methods a field of the establishment profile, filled once at registration and attached automatically to every publication.
- Solution: Add accepted payment methods as a one-time field in the establishment profile, shown on every publication and available as a feed filter, with a post-visit correction option for students when the information is outdated.
-
Type 2 (Direct user experience improvement): Do students who view a menu post within the first hour after it's published report it as outdated less often than those who view it later — suggesting that menu freshness directly reduces friction in their decision-making?
-
Type 3 (New or deprecated/updated features): Would adding a "still accurate" confirmation button (letting students confirm a menu is still correct, not just report it as outdated) reduce false expirations and increase trust in the feed compared to only having a "report outdated" option?
- Type 2 (Direct user experience improvement): Do publications from establishments with a storefront photo and verified location get selected more often than publications without them, when both appear in the same feed session for the same student?
- Type 2 (Direct user experience improvement): Among students who select a publication and then travel to the establishment, does the rate of abandonment or "couldn't find it" reports differ between listings with complete location information and listings without?
-
Type 2 (Direct user experience improvement): Which currently valid menu publication should UniEat place first for a student, given their selected budget, dietary requirements, current location, and available minutes, so that they can choose a feasible option without manually comparing every publication?
-
Type 3 (New or deprecated/updated features): Would adding a crowd-updated waiting-time indicator to menu publications reduce the percentage of selections followed within ten minutes by either a "line too long" report or the selection of a different establishment, compared with the current feed without that indicator?
- Type 3: Would replacing free-text menu entries with a structured form requiring price range, category, and dietary tags raise the share of posts students can filter and compare directly, compared with the free-text format used today? Why Type 3: The answer decides whether UniEat keeps free-text posting or replaces it with a structured form. That's a call about adding, changing, or dropping a piece of functionality,and we ask the question to decide on implementing a new feature or updating an existing one.
- Type 4: Which food categories and price ranges draw the most student attention across the feed, information UniEat could package as demand insight for restaurants or vendors deciding whether to open near campus? Why Type 4: The student who generates this data gets nothing back from the answer. The value goes to an establishment or vendor deciding where to set up shop, using UniEat's aggregated data about what students actually want.
-
Type 1 (App's telemetry): When and under which conditions does the feed fail to load or take longer than expected — broken down by hour of the day, connection type, device model and OS version — and what share of sessions ends without a single publication being displayed? Why Type 1: It is answered entirely with the app's own instrumentation. No user opinion is involved and the object of study is the technical behavior of UniEat itself, not the food or the establishments.
-
Type*: Do sessions affected by slow or failed feed loads during the midday peak end without any menu selection more often than unaffected sessions, and would serving a locally cached copy of the last valid feed reduce that abandonment? Why Type*: It combines three types. The first half is Type 1, since latency and error rates come from telemetry. The outcome measured — the student leaving without choosing anything — is Type 2. And the answer decides whether we build the local cache, which makes it Type 3 as well.
| # | Business Question | Type | Data Source | Visualization |
|---|---|---|---|---|
| 1 | When and under which conditions does the feed fail to load or take longer than expected, and what share of sessions ends without a single publication being displayed? | 1 | Telemetry events: feed request start and end timestamps, outcome (success, timeout, error) and error type, connection type, device model, OS version, app version, session ID | Heatmap of median load time and failure rate by hour of day against connection type, with a ranked table of the device and OS combinations most affected |
| 2 | Do students who view a menu post within the first hour after it's published report it as outdated less often than those who view it later — suggesting that menu freshness directly reduces friction in their decision-making? | 2 | Publication timestamp; feed impression events with view timestamp and publication ID; "outdated" reports with timestamp and publication ID | Line chart of the outdated-report rate against the age of the publication at view time, bucketed by hour since publication |
| 3 | Do publications from establishments with a storefront photo and verified location get selected more often than publications without them, when both appear in the same feed session for the same student? | 2 | Publication metadata with a completeness flag (storefront photo present, location verified); feed impressions per session; selection events with session ID and timestamp | Grouped bar chart comparing selection rate for complete vs. incomplete listings, restricted to sessions where both appeared |
| 4 | Among students who select a publication and then travel to the establishment, does the rate of abandonment or "couldn't find it" reports differ between listings with complete location information and listings without? | 2 | Selection events; arrival confirmations (check-in); report categories including "couldn't find it"; time between selection and arrival or abandonment | Funnel from selection to arrival split into complete vs. incomplete listings, with drop-off rate labeled at each stage |
| 5 | Which currently valid menu publication should UniEat place first for a student, given their selected budget, dietary requirements, current location, and available minutes, so that they can choose a feasible option without manually comparing every publication? | 2 | Current valid menu publications: dish, price, dietary tags, publication and expiration timestamps, establishment coordinates; student-selected budget, dietary requirements and available minutes; device location with permission | Personalized ranked feed with a highlighted top recommendation and an explanation of the constraints it satisfies |
| 6 | Would adding a "still accurate" confirmation button (letting students confirm a menu is still correct, not just report it as outdated) reduce false expirations and increase trust in the feed compared to only having a "report outdated" option? | 3 | A/B-test cohort; "still accurate" confirmations and "outdated" reports with timestamps; publication lifetime and reason for removal from the feed (expired by time, hidden by reports); post-visit confirmations of whether the publication matched reality | Grouped bar chart comparing, between cohorts, the share of publications hidden while still accurate and the share of selections later confirmed as matching |
| 7 | Would adding a crowd-updated waiting-time indicator to menu publications reduce the percentage of selections followed within ten minutes by either a "line too long" report or the selection of a different establishment, compared with the current feed without that indicator? | 3 | A/B-test cohort, initial and subsequent menu selections, interaction timestamps, "line too long" reports and waiting-time indicator interactions | Comparative bar chart showing reselection or long-line-report rates for the feed with and without the waiting-time indicator |
| 8 | Would replacing free-text menu entries with a structured form requiring price range, category, and dietary tags raise the share of posts students can filter and compare directly, compared with the free-text format used today? | 3 | A/B-test cohort assigned by establishment (free-text vs. structured form); publication ID and posting format; completion and validation status for category, price range, and dietary tags; flag indicating whether the publication is filterable and comparable; filter-query and result events with timestamps | Grouped bar chart comparing the percentage of filterable and comparable publications in the free-text and structured-form cohorts, with separate bars for category, price range, dietary tags, and all three fields |
| 9 | Which food categories and price ranges draw the most student attention across the feed, information UniEat could package as demand insight for restaurants or vendors deciding whether to open near campus? | 4 | Publication metadata: food category and price range; anonymized feed-impression, detail-open, menu-selection, and arrival-confirmation events linked by publication ID and session; day, time, and campus area for aggregation | Bubble heatmap with food category on the rows and price range on the columns; cell color represents selection rate (selections divided by impressions) and bubble size represents the number of unique students selecting, with filters for day, time, and campus area |
| 10 | Do sessions affected by slow or failed feed loads during the midday peak end without any menu selection more often than unaffected sessions, and would serving a locally cached copy of the last valid feed reduce that abandonment? | * | Load latency and error events per session; session outcome (selection made or session closed with no selection); A/B cohort assignment (cache enabled or disabled); cache-hit events with the age of the served copy | Dual-axis chart per hour of the day: line for median load latency and bars for the no-selection rate, with cohort comparison between the cached and non-cached versions |
Link to online version: https://drive.google.com/file/d/1Pz2kCxq76iG9qwEMgiix0MqkGkczfAtf/view?usp=sharing