Table of contents

• Proposed Solution
• Description of problems, alternatives and solutions
• Context Canvas
• Description of personas
• Empathy Maps
• Business Questions
• VD Map
• Functional Scenarios
• Quality Scenarios
• Ethics Video

Proposed Solution

Description of the selected problem

There are a large number of restaurants, cafes, and snack spots around the Universidad de los Andes, but there is no centralized platform where students can discover and compare these dining options. Currently, students rely on a fragmented mix of Instagram, visiting restaurants to check menus, word of mouth, and WhatsApp groups to decide where to eat, a process that is slow, inconsistent, and fails to account for personal constraints such as budget, dietary preferences, or limited free time between classes. This leads to recurring frustrations, such as arriving at crowded places during peak hours without knowing it beforehand, being disappointed despite having done research beforehand, and ending up repeating the same choices because they can’t find alternatives that fit their constraints.

Description of the proposed solution

Our proposed solution is a mobile application that centralizes the gastronomic offer available around Universidad de los Andes and supports users throughout the process of discovering, comparing, and selecting where to eat. Instead of requiring users to search through multiple social networks, maps, or recommendations from other people, the application provides a single platform where relevant information about nearby restaurants and food options can be explored in a structured and accessible way. The application allows users to discover restaurants from a personalized home screen, search for specific places or food categories, and explore nearby options through an interactive campus map. Each restaurant can provide relevant information such as its location, type of food, estimated price range, opening hours, dietary alternatives, and other characteristics that can influence the user's decision. Users can also save their favorite places and complete a preference survey that helps the application understand factors such as preferred cuisines, budget, and dietary restrictions. Additionally, the proposed solution seeks to reduce uncertainty during the decision-making process by incorporating information such as estimated crowd levels and waiting times. By combining restaurant information, user preferences, location, and interaction data, the application can provide more relevant recommendations and help users quickly identify alternatives that fit their current needs. The main capabilities of the proposed solution include:

• A Home Discover section with restaurant suggestions and relevant food options.
• A Search functionality to find restaurants based on specific criteria.
• An interactive Campus Map displaying nearby gastronomic options.
• Detailed restaurant information to support comparison between alternatives.
• A Preference Survey to identify user interests, budget, dietary restrictions, and food preferences.
• Personalized recommendations based on user preferences and interactions with the application.
• Information about estimated crowd levels and waiting times to support faster dining decisions.
• The possibility of saving and revisiting favorite restaurants.

Revenue model

Since the target audience consists of college students on a tight budget, charging for app usage or specific features is not a viable primary strategy, as it would discourage adoption of the product. Therefore, the revenue model is based on a source that does not rely on the end user: As a team, we evaluated three monetization options for the app:

• Standard in-app advertising: conventional ad spaces (banners, sponsored content) targeted at businesses in the food and beverage sector and other advertisers interested in the student population.
• Commissions and paid advertising from partner restaurants: businesses near campus paying to appear prominently in search results or on the map, or through a commission on interactions facilitated by the app.
• Data monetization: selling insights derived from user reviews to restaurants (for feedback) and new businesses (to understand the market) in an anonymous and aggregated form.

Ultimately, we decided on standard advertising. We chose this option because it’s the simplest to implement at this stage, doesn’t rely on restaurants paying to appear (which makes it easier to build a broad selection from the start), and scales naturally with user growth, without the need for external commercial agreements. Since students have limited budgets, any model that relied on charging them directly wasn’t viable.

Value proposal

For students, the app saves time and reduces uncertainty by centralizing in one place information that is currently scattered across multiple platforms, and it personalizes recommendations based on their budget, dietary restrictions, and free time between classes, all at no cost to them. For partner restaurants, the app offers targeted visibility to a high-volume, repeat-business college audience, something that’s difficult to achieve through generic channels like social media or conventional maps.

Description of problems, alternatives and solutions

The following Problems-Alternative-Solutions (PAS) were defined based on the needs and pain points identified for the prospective users and the analytics persona. For each problem, we considered how the persona currently addresses the issue and proposed a solution that improves the current alternative through the application's functionality and analytics capabilities.

ID	Problem	Alternative	Solution
1	Students and university staff have difficulty discovering the variety of restaurants and food options available around Universidad de los Andes because the information is fragmented across multiple sources.	Users rely on Instagram, TikTok, Google Maps, recommendations from friends, or the restaurants they already know.	The app centralizes the gastronomic offer in a single platform where users can discover and explore nearby restaurants and food options.
2	Users have limited time between classes or university activities and may spend too much time comparing different places before deciding where to eat.	Users manually search different platforms, ask friends, or choose a familiar restaurant to avoid spending additional time deciding.	The app provides search, filters, restaurant details, and personalized recommendations that allow users to quickly identify options that match their current needs.
3	A student with only 30 minutes between classes may choose a restaurant without knowing whether the current waiting time will allow them to eat and return to class on time.	The student walks to the restaurant, checks the line in person, or asks friends nearby before deciding whether to stay or look for another option.	The app displays estimated waiting times and crowd levels for nearby restaurants, allowing the student to compare alternatives before leaving campus.
4	Users may arrive at a restaurant without knowing that it is crowded or that the expected waiting time is too long for the time they have available.	Users walk to the restaurant and check the situation in person, ask friends who are nearby, or choose another place after arriving.	The app provides estimated crowd levels and waiting times so users can compare options before going to a restaurant.
5	A user with a vegetarian or vegan diet may find a restaurant that looks suitable but later discover that it has very few options that match their dietary restriction.	The user checks restaurant menus individually, searches social media posts, or asks restaurant staff before deciding where to eat.	The app stores dietary attributes for each restaurant and allows users to filter the gastronomic offer specifically by vegetarian, vegan, or other dietary options.
6	Users have different budgets, dietary restrictions, and food preferences, making it difficult to identify restaurants that are suitable for them.	Users manually inspect menus, social media posts, restaurant information, or ask other people before deciding whether a place fits their needs.	The app allows users to provide their preferences and constraints and uses this information to filter options and generate more personalized restaurant recommendations.
7	A student with a fixed lunch budget may spend time opening several restaurant profiles just to determine which places are affordable.	The student checks menus one by one, asks friends about prices, or repeatedly visits restaurants whose prices are already familiar.	The app allows users to define a preferred price range and filters or prioritizes restaurants whose estimated prices fall within that budget.
8	The Product Manager lacks a clear understanding of which restaurants, food categories, and application features generate the most interest among users.	She relies on user interviews, informal feedback, and manual observations to infer what users prefer and how they interact with the platform.	The platform aggregates interaction data such as searches, restaurant views, favorites, and feature usage to identify user behavior patterns and support evidence-based product decisions.
9	Users may repeatedly choose the same restaurants because they do not know which less familiar places offer food similar to what they already enjoy.	They rely on recommendations from friends, social media posts, or continue visiting the same known restaurants.	The app uses the user's selected cuisine preferences, favorites, and previous interactions to recommend less familiar restaurants with similar characteristics.
10	The Product Manager cannot easily identify whether users abandon the restaurant discovery process after performing a search without opening any restaurant.	She reviews general usage metrics or user feedback, but cannot determine at which specific point users stop interacting with the search flow.	The platform records search events, result impressions, restaurant-detail openings, and subsequent actions so the Product Manager can identify searches that frequently end without meaningful interaction.
11	The Product Manager cannot easily determine whether personalized restaurant recommendations are relevant and useful to users.	She relies on occasional feedback or general application usage without directly measuring how users interact with the recommendations they receive.	The platform tracks interactions with personalized recommendations, such as recommendation views, restaurant detail visits, and favorites, allowing the Product Manager to evaluate their effectiveness and identify opportunities to improve personalization.
12	The Product Manager does not know which filters actually help users narrow down restaurant options and which filters are rarely used or provide little value.	She relies on assumptions, interviews, or occasional feedback when deciding whether a filter should be maintained, changed, or removed.	The analytics system tracks how frequently each filter is selected and whether filtered searches lead to restaurant-detail views or favorites, allowing the Product Manager to evaluate the usefulness of each filter.

Context Canvas

Description of Personas

Persona 1

Persona 2

Persona 3

Analytics Persona

Empathy Maps

Empathy Map 1

After conducting two interviews, we found the first prospective user: a member of the university community who invest time and effort in doing research before choosing where to eat near campus. They check reviews on Instagram or TikTok and is influenced by a place’s popularity or recommendations from friends, but they discover that this preliminary research doesn’t guarantee a good experience: as happened to Karim, who arrived with high expectations at a spot very popular among students and ended up disappointed because “the burger wasn’t that good,” or as Ana María describes it more subtly, acknowledging that even when she’s seen very good reviews, she sometimes ends up disappointed and admits that “it’s not so certain that the effort was worth it.” This user experiences a constant tension between the effort they put into gathering information and the real uncertainty of whether that information will translate into a good decision, which gradually erodes their trust in the sources they use to choose where to eat.

Link to the empathy map

Empathy Map 2

We identified a second prospective user: a student with very limited time between clases who prioritizes speed, proximity, and predictable when choosing where to eat. Karim mentioned that she sometimes has only around thirty minutes between classes, while Ana María also tends to repeat familiar options when time is limited. This user is mainly affected by the uncertainty of waiting times and distance, which often leads them to choose nearby, known restaurants instead of exploring new alternatives.

Link to the Empathy Map

Empathy Map 3

We identified a third prospective user, a student with specific dietary preferences who looks for balanced, affordable, and suitable food options near campus. Ana María, for example, follows a vegetarian diet and often returns to familiar restaurants because she already knows they offer meals that fit both her nutritional expectations and budget. Although there is a wide gastronomic offer around the university, this user faces fewer realistic options once dietary needs, price, variety, and available time are considered together, which often leads them to rely on the same trusted places instead of exploring new alternatives.

Link to the Empathy Map

Empathy Map 4

We identified a fourth prospective user: a student with a limited food budget who wants to find affordable options near campus without sacrificing quality or variety. This user usually compares prices, checks menus, looks for promotions or lunch specials, and often returns to familiar places where they already know how much they will spend. However, prices are not always clearly available online and promotions can change frequently, making it difficult to know which option offers the best value. As a result, this user may feel frustrated or limited by their budget and tends to prioritize restaurants with predictable prices and a good price–quality balance instead of exploring more expensive or unfamiliar alternatives.

Empathy Map 5

We identified a fifth prospective user: a student who usually eats with a large group of friends and struggles to find a place where everyone agrees and can sit together. This user experiences the constant tension of balancing different cravings, individual budgets, and the physical space available at nearby restaurants. The challenge of group decision-making often wastes a significant portion of their short break time, which frequently leads them to compromise on their preferred food or settle for the same familiar spot just to avoid further arguing and ensure the whole group can actually eat together.

Link to the Empathy Map

Empathy Map 6

We identified a sixth prospective user: a student on a strict daily budget who wants to find affordable, filling meals near campus without sacrificing quality. This user is highly sensitive to the elevated prices of many popular spots and the hidden costs of eating out, constantly searching for daily specials, combos, or student discounts to make their weekly allowance last. They are mainly affected by the financial stress of dining around campus, which often leads them to walk further away to find cheaper alternatives, skip buying drinks, or feel excluded when their friends choose more expensive restaurants.

Link to the Empathy Map

Business Questions

Type 1: App’s telemetry

• On avarage, how many times does a user open the app during a typical academic week?
• How long does it take for the real-time occupancy indicator to update after a place reports its status?

Type 2: Direct user experience improvement

• Which filters (diet, budget, distance, available time) are most commonly used when searching for a place to eat?
• How long does it take, on average, for a user to go from opening the app to selecting a place to eat?
• What percentage of users complete the food preferences survey during onboarding?
• How often do users check or inquire about a restaurant’s occupancy level before deciding to go?

Type 3: New or deprecated/updated features

• What categories of food or restaurants do users search for without getting any results (gaps in the listed offerings)?
• What places are saved as favorites but rarely viewed in detail again?
• Which sections of the prototype (map, filters, details, favorites) receive the least interaction and could be redesigned or removed?
• How often do users go back and edit their saved dietary preferences after their first use?

Type 4: Benefits from data

• What patterns of traffic by time slot could be shared with partner restaurants to help them better manage their peak hours?
• What type of report based on anonymous reviews (visit volume, recurring complaints, overall sentiment) would be most valuable to offer partner restaurants?

Type 5: combination of two or more types

• How does the use of the “free time between classes” filter relate to the likelihood that the user will actually visit the recommended location?
• How does a place's real-time occupancy level relate to how often users end up choosing an alternative recommended place?

VD Map

Functional Scenarios

Functional Scenarios describe how prospective users interact with the main features of the application in realistic situations. The scenarios follow the structure proposed in the book, combining the user's context or need, the expected outcome, and the interaction performed with the application.

1. As a student looking for a place to eat near Universidad de los Andes, I want to browse the available gastronomic options around campus, so I can discover restaurants beyond the places I already know. (Scrolling on the screen)

2. Given that I have a specific type of food in mind, I want to search restaurants by name or food category, so I can quickly find options that match what I want to eat. (Typing on the keyboard)

3. Given that I am vegetarian or have another dietary restriction, I want to filter the available restaurants by dietary options, so I only see places that can satisfy my needs. (Clicking on the screen)

4. As a student with a limited budget, I want to filter or compare restaurants according to their price range, so I can identify options that fit the amount of money I am willing to spend. (Clicking on the screen)

5. Given that I have limited time between classes, I want to see the estimated waiting time or crowd level of a restaurant, so I can avoid choosing a place where I may not have enough time to eat. (Scrolling on the screen)

6. As a student who does not know all the gastronomic options around campus, I want to explore restaurants through a map, so I can understand where each option is located relative to my current position. (Dragging and clicking on the map)

7. Given that I am comparing different alternatives, I want to open the detailed information of a restaurant, so I can review its cuisine type, approximate price, location, opening hours, and dietary options before deciding where to eat. (Clicking on the screen)

8. As a user with particular food preferences, I want to complete a preference survey with information such as my preferred cuisines, budget, and dietary restrictions, so the application can provide recommendations that are more relevant to me. (Selecting options on the screen)

9. Given that I have already provided my preferences and interacted with restaurants in the application, I want to receive personalized restaurant recommendations, so I can discover places that are more likely to match my interests. (Scrolling on the Home Discover screen)

10. As a user who finds a restaurant that I like or want to visit later, I want to save it as a favorite, so I can easily find it again without repeating the search process. (Clicking on the favorite button)

11. Given that I have saved several restaurants as favorites, I want to access my saved places from one section of the application, so I can quickly reconsider restaurants that previously caught my attention. (Clicking and scrolling on the screen)

12. Given that the recommendations initially shown do not match what I currently want to eat, I want to modify my search criteria or preferences, so the application can show alternatives that better match my current needs. (Typing and selecting filters on the screen)

Quality scenarios

Quality scenarios describe how the application should react when changes in the execution context affect its normal operation. Each scenario identifies the relevant quality attributes, the current status of the application, the contextual change, and the expected system reaction.

Scenario	1
Scenario Name	Loss of Connectivity During Restaurant Search
Quality Attributes	Availability, Resilience, Usability
App Status	The user is browsing restaurant options around Universidad de los Andes and has already loaded a list of gastronomic places.
Changes in the context	While the user performs a new search or changes a filter, the mobile device temporarily loses its internet connection.
System reaction	The application remains stable, informs the user that the connection has been lost, preserves previously loaded information when possible, and allows the user to retry once connectivity is restored.

Scenario	2
Scenario Name	High Demand During Lunch Hours
Quality Attributes	Performance, Scalability, Availability
App Status	The application is operating normally and users are searching, filtering, and browsing restaurant options around campus.
Changes in the context	During the main lunch period, a significantly larger number of students simultaneously access the application.
System reaction	The system continues processing requests without becoming unavailable, and searches, filters, and restaurant detail views continue responding within an acceptable time.

Scenario	3
Scenario Name	Personalized Recommendations Cannot Be Generated
Quality Attributes	Availability, Resilience, Usability
App Status	The user has previously completed the preference survey and has interaction history used for personalized recommendations.
Changes in the context	The application is temporarily unable to generate or retrieve personalized recommendations.
System reaction	The application continues showing general gastronomic options and keeps search, filters, map, and restaurant details available.

Scenario	4
Scenario Name	Crowd or Waiting-Time Information Is Not Current
Quality Attributes	Data Accuracy, Reliability, Usability
App Status	The user is evaluating a restaurant and checks its estimated crowd level or waiting time.
Changes in the context	The application cannot obtain updated crowd or waiting-time information.
System reaction	The application indicates that the estimate may be outdated and still allows the user to access the rest of the restaurant information and compare alternatives.

Scenario	5
Scenario Name	Search Results Take Too Long to Update
Quality Attributes	Performance, Responsiveness, Usability
App Status	The user is viewing restaurant search results and applies a new filter such as price range, food category, or dietary restriction.
Changes in the context	The backend takes longer than expected to process the new filter combination and return updated results.
System reaction	The application keeps the interface responsive, shows a loading indicator, and updates the results as soon as the filtered information is available without freezing the current screen.

Scenario	6
Scenario Name	Map Data Fails to Load
Quality Attributes	Availability, Resilience, Usability
App Status	The user opens the map to explore restaurants near Universidad de los Andes.
Changes in the context	The map data or restaurant location information cannot be loaded temporarily.
System reaction	The application informs the user that the map information is unavailable and allows them to continue discovering restaurants through search, filters, or other available sections of the app.

Scenario	7
Scenario Name	Favorite Restaurant Cannot Be Saved
Quality Attributes	Reliability, Availability, Usability
App Status	The user is viewing a restaurant detail page and attempts to add the restaurant to their favorites.
Changes in the context	The request to save the favorite cannot be completed because the service is temporarily unavailable.
System reaction	The application informs the user that the restaurant could not be saved, keeps the current restaurant information visible, and allows the user to retry the action later.

Scenario	8
Scenario Name	Restaurant Information Is Incomplete
Quality Attributes	Reliability, Data Accuracy, Usability
App Status	The user opens a restaurant detail page to compare information such as price range, dietary options, opening hours, and location.
Changes in the context	One or more restaurant attributes are unavailable or missing from the data source.
System reaction	The application clearly indicates which information is unavailable instead of displaying incorrect or fabricated values, while still presenting the remaining restaurant information.

Scenario	9
Scenario Name	Application Rotated
Quality Attributes	Responsiveness, Usability
App Status	The user is browsing gastronomic options, using the map, applying filters, or viewing the details of a restaurant.
Changes in the context	The user rotates the device 90° from portrait mode to landscape mode.
System reaction	The application remains in portrait mode and preserves the current screen and user progress without interrupting the ongoing interaction.

Scenario	10
Scenario Name	Screen Size Changes
Quality Attributes	Responsiveness, Usability
App Status	The user is browsing Home Discover, search results, the map, or restaurant details on a supported mobile device.
Changes in the context	The application is opened on a device with a different screen size or resolution.
System reaction	The interface adapts to the available screen dimensions without hiding essential information, overlapping controls, or preventing access to core functionality.

Scenario	11
Scenario Name	Crash in the Application
Quality Attributes	Usability, Reliability
App Status	The application is running and the user is browsing gastronomic options, viewing restaurant details, or using search and filters.
Changes in the context	An unexpected bug or internal error occurs, causing the application to crash.
System reaction	The application collects relevant crash information and sends it to the backend service for analysis. When the user reopens the app, the system starts normally and informs the user that an unexpected error occurred.

Scenario	12
Scenario Name	Favorite Not Saved Due to Lost Connection
Quality Attributes	Resilience, Eventual Connectivity
App Status	The user is viewing a restaurant and selects the option to save it as a favorite.
Changes in the context	The internet connection is lost before the favorite is successfully saved in the backend.
System reaction	The application temporarily stores the favorite action locally. When the internet connection is restored, the application sends the pending request to the backend and synchronizes the user's favorites.

Ethics Video

Ethics Video On Youtube

In Case the one above doesn't work Ethics Video on Onedrive