Repository navigation
Sprint 1
Project: UniEat — Daily Menu Feed Course: ISIS-3510 — Construcción de Aplicaciones Móviles Team members:
Juan Esteban Rojas Castañeda
Camilo Andres Molina Plata
Kevin David Alvarez Romero
Juan Jose Murillo Aristizabal
Samuel David Rozen Mogollon
- Problem, Solution and Business Model
- Problems, Alternatives and Solutions
- Context Canvas
- Personas
- Empathy Maps
- Business Questions
- Value-Driven Map
- Functional Scenarios
- Quality Scenarios
- Ethics Video
- Collaboration and Project Management
- Supporting Evidence and References
The selected problem is the difficulty university students face when discovering, comparing, and locating food options on and around the Universidad de los Andes campus. The interviews identified information gaps concerning current menus, prices, dietary options, location, and waiting times.
These gaps become particularly relevant when students need to eat between classes. Their decision must account for their budget, the time available, and the distance to their next activity. Finding missing information by walking between establishments consumes part of the same break they need for eating.
The project focuses on access to current food information at the moment of deciding. This focus led to the selection of UniEat — Daily Menu Feed, through which establishments would publish their daily offers and students would compare them before travelling.
The research supporting this problem consists of three food-related interviews. Their findings inform the proposed design; they do not establish how frequently these difficulties occur across the entire student population.
| Evidence and attribution | Relevant findings | Design implication |
|---|---|---|
| Interview 1 — Cristal, conducted by Juan Esteban Rojas Castañeda. MS2 situations. | Cristal discovers establishments through classmates, considers food type, price, and distance, and returns to familiar places when she does not know the alternatives. | Make nearby alternatives visible and provide comparable information before the student decides where to go. |
| Interview 3 — Allison, conducted by Kevin Alvarez. MS2 situations. | Allison considers price, location, quality, and service speed. She consults friends and online sources, and described difficulty finding a recommended establishment with an unclear facade or entrance. | Combine relevant decision information with location references that help students recognize the establishment. |
| Interview 6 — Santiago, conducted by Camilo Molina. MS3 interview notes. | Santiago abandoned an establishment because of its queue, struggled to find current menus and prices, and described a group spending twenty minutes comparing options compatible with their budgets and a vegetarian requirement. | Support comparison using current menu information, price and dietary filters, and an estimate of waiting conditions. |
Together, these accounts identify a gap between knowing that food establishments exist and having enough current information to choose a suitable option. Students use friends, online content, and physical exploration, but these sources did not consistently provide the information the participants needed at the time of their decisions.
UniEat — Daily Menu Feed is a proposed mobile application where food establishments on and around campus publish what they are offering that day.
Each menu publication would include dishes, prices or clearly identified approximate prices, publication time, a validity window, and a link to the establishment's profile. Students would browse current publications, compare alternatives, and review location information before travelling.
The organizing unit is a time-bounded menu publication. Automatic expiry would hide or flag publications after their validity window, while student reports would help identify changes occurring before expiry, such as unavailable dishes or outdated prices. These mechanisms aim to reduce outdated information; their effectiveness depends on timely publications and reliable updates.
The design serves two main groups:
- Students, who consult and compare food options and can report discrepancies after visiting.
- Establishment owners or managers, who publish their offers, maintain their profiles, and review publication performance.
The daily menu feed was selected in the MS3 decision process. The MS4 PAS hypotheses subsequently refined the proposal with waiting-time information, publication analytics, and other supporting capabilities.
The following capabilities describe the proposed design. Their impact remains to be evaluated.
| Capability | Proposed behavior | Supporting evidence or design source |
|---|---|---|
| Daily menu feed | Bring today's menu publications together so students can compare dishes and prices before travelling. | Interviews 1, 3, and 6; selected solution in MS3. |
| Publication validity and corrections | Display publication and expiry information, hide or flag expired offers, and allow students to report discrepancies or unavailable items. | MS3 smart components; MS4 PAS 1. |
| Filters and relevance ordering | Help students find publications matching their stated budget, dietary requirements, location, and available time. Structured menu fields support comparison. | Interview 6; MS4 PAS 5 and PAS 7. |
| Location and establishment details | Show the map location, storefront reference, and available profile information, including accepted payment methods. Clearly indicate missing profile details. | Interview 3; MS4 PAS 3 and PAS 10. |
| Waiting-time indicator | Provide an estimated wait using recent student reports and historical patterns. Indicate when the information was updated or when there is insufficient evidence for an estimate. | Interview 6; MS4 PAS 6. |
| Access during connectivity interruptions | Display the last successfully loaded feed with its retrieval time, while excluding publications that have already expired. | MS4 PAS 9; proposed contextual requirement. |
| Publication performance view | Show establishments the impressions, detail openings, and arrival confirmations associated with their publications. | MS4 PAS 4; proposed establishment-facing capability. |
The waiting-time indicator addresses the feedback about queues by helping students assess an option before walking there. It would communicate an estimate rather than guarantee an exact waiting time.
Publication status must also remain explicit: “no current menu published” describes missing information. An establishment's opening status requires separate supporting information.
For students
UniEat aims to help students choose a food option that fits their budget, dietary requirements, location, and available time before they start travelling. Its expected value is less effort spent gathering information and fewer unnecessary trips to establishments that do not meet their needs.
For Alex and Diego, the prospective personas developed in MS3, this means having clearer information for decisions made during short breaks or while moving between buildings.
For establishments
UniEat would provide a channel for presenting current offers to students looking for food nearby. Publication performance information would help owners understand whether their posts attract attention and lead to reported arrivals.
These metrics represent engagement with the application. Any relationship with purchases or increased sales would require additional evidence.
Differentiation from current alternatives
The proposed distinction is the combination of campus relevance, time-bounded menu publications, comparable prices and dietary information, location references, and waiting-time estimates in one decision flow.
This responds to the fragmented information described by the interview participants. The expected benefits have not yet been measured through a deployed application.
Status: proposed business-model hypothesis, pending validation.
The previous deliverables identify potential value for establishments through publication performance and aggregated demand information. They do not establish a pricing model or demonstrate willingness to pay.
The proposed model is to keep food discovery and basic publication accessible while offering optional paid analytics to establishments.
| Component | Proposed approach |
|---|---|
| Student access | Free access to menu discovery, comparison, location information, and reporting. |
| Basic establishment participation | Free establishment profile, daily menu publication, and basic publication performance information. |
| Paying customer | Establishment owners or managers who find additional value in more detailed performance and demand analysis. |
| Revenue mechanism | An optional monthly subscription for advanced analytics. |
| Paid value | Historical publication trends, comparisons across an establishment's own posts, and aggregated insights into food categories, price ranges, and periods attracting student attention. |
| Main costs to assess | Application hosting, image storage, data processing, maintenance, moderation, and establishment onboarding and support. |
This proposal builds on two elements already documented in MS4:
- PAS 4: a performance view showing publication impressions, openings, and arrival confirmations.
- The Type 4 business question: aggregated information about food categories and price ranges that attract student attention, potentially useful to restaurants or vendors considering opportunities near campus.
Source: MS4 — PAS and Business Questions.
Free basic participation is proposed to lower the initial effort required to join and maintain current publications. The paid tier would need to provide useful additional analysis beyond those basic capabilities.
Before adopting this model, the team would need to validate:
- Whether owners would publish and update menus consistently.
- Which additional insights would support decisions they actually make.
- Whether they would pay for those insights and at what price.
- Whether the application could collect enough reliable interaction data to produce useful aggregated reports.
This section consolidates the ten PAS hypotheses developed in MS4, preserving two contributions per team member.
Each entry identifies a problem, alternative approaches, a proposed solution, and its rationale. The evidence basis distinguishes interview findings from anticipated operational or contextual risks.
All proposed solutions remain design hypotheses. Interview evidence supports the underlying needs; their effectiveness requires subsequent evaluation. Alternatives include documented current practices and, for anticipated product risks, design approaches considered by the team.
| Field | Description |
|---|---|
| Problem | A menu publication may become inaccurate before its validity window ends. A dish could sell out or its price could change while students still see the original information. |
| Alternatives | Rely on automatic expiration; depend on establishments manually updating every change; or allow students to report discrepancies after visiting. |
| Solution hypothesis | Provide a quick reporting option for unavailable dishes or price discrepancies. Flag affected publications and reduce their visibility, identifying the information as a reported change pending confirmation. |
| Rationale | Student reports could warn others about changes that time-based expiration alone cannot detect. |
| Evidence basis | Anticipated information-maintenance risk identified in MS4 PAS 1. Interview 6 supports the need for current menus and prices, but does not validate this reporting mechanism. |
| Field | Description |
|---|---|
| Problem | An establishment may forget or delay publishing its daily menu. Without an explicit status, students could interpret the missing publication as an absence of food options. |
| Alternatives | Leave the listing empty; remind establishments to publish; or display an explicit status when no current menu exists. |
| Solution hypothesis | Send registered establishments a daily publication reminder and display “No menu published today” when a current publication is missing. Maintain opening status separately. |
| Rationale | Reminders could support consistent publishing, while an explicit status helps students understand what information is available. |
| Evidence basis | Publication consistency is an operational hypothesis from MS4 PAS 2. Santiago's account of uncertainty about evening options motivates clearer availability information (I6-S3). |
| Field | Description |
|---|---|
| Problem | A student may know an establishment's name and still struggle to recognize its entrance, spending additional time searching after choosing where to eat. |
| Alternatives | Follow an address using an external map; consult descriptions or photographs shared by previous visitors; require complete location references during registration; or allow optional references and identify missing information. |
| Solution hypothesis | Allow establishments to add a precise location reference, storefront photograph, and entrance description. Display available references alongside menu publications and indicate which details are missing. Keep supplementary location references optional during registration. |
| Rationale | Visual and location references could help students recognize the correct entrance while keeping initial registration manageable for establishments. |
| Evidence basis | Allison described difficulty locating a recommended establishment because its facade and signage were unclear (I3-S3). The proposed registration approach remains a design choice. |
| Field | Description |
|---|---|
| Problem | Establishment owners may be reluctant to maintain daily publications if they cannot observe whether students interact with them. The effect on continued participation remains uncertain. |
| Alternatives | Provide no performance feedback; send periodic summaries outside the application; or offer a basic performance view within UniEat. |
| Solution hypothesis | Provide a free basic dashboard showing each publication's impressions, detail openings, and student-reported arrivals. Present each metric with a clear definition. |
| Rationale | Visible engagement information could help owners assess the usefulness of publishing and identify posts that attract attention. These metrics describe application interactions and reported visits. |
| Evidence basis | Establishment-participation hypothesis from MS4 PAS 4. It requires validation with owners. Free basic metrics are consistent with the proposed business model in Section 1.6. |
| Field | Description |
|---|---|
| Problem | Students with limited breaks need food options compatible with their budget, location, available time, and dietary requirements. Gathering this information from several sources makes comparison difficult. |
| Alternatives | Ask friends, consult reviews or social media, walk between establishments, or return to a familiar option. These practices appear in the food-related interviews. |
| Solution hypothesis | Filter out expired publications and order the remaining options using the student's selected constraints and available menu information. Explain the matching criteria and identify missing information. Treat time compatibility as an estimate dependent on available travel and waiting information. |
| Rationale | Comparing relevant publications in one place could reduce the effort required to identify a suitable option. |
| Evidence basis | Cristal and Allison described price and location criteria (I1-S3, I3-S1). Santiago described a group struggling to reconcile budget and vegetarian requirements (I6-S2). |
| Field | Description |
|---|---|
| Problem | A menu and price may fit a student's needs, but a long queue can make the establishment impractical within the available break. Discovering the queue after walking there adds further time pressure. |
| Alternatives | Inspect the queue in person, ask friends about current conditions, leave after seeing the line, or choose another establishment along the route to class. |
| Solution hypothesis | Add a waiting-time estimate to current menu publications using recent student reports and historical reports from comparable periods. Reduce the influence of older reports, display information freshness, and show “Insufficient information” when an estimate cannot be supported. |
| Rationale | An estimate could help students consider waiting conditions before travelling and reduce avoidable changes of destination. |
| Evidence basis | Santiago abandoned a queue and chose a vendor on his way to class. He identified line length as a decisive factor (I6-S1, I6-Q2, I6-Q9). The estimation method remains unvalidated. |
| Field | Description |
|---|---|
| Problem | Students need comparable food and price information. If publications use unrestricted text, inconsistent descriptions may make reliable filtering and comparison difficult. |
| Alternatives | Use free-text menus and require manual comparison; extract categories and prices from text; or collect information through a structured publication form. |
| Solution hypothesis | Provide structured fields for dishes, category, price or clearly identified price range, and dietary information. Allow establishments to indicate when dietary information is unknown. Use these fields consistently in filters and comparisons. |
| Rationale | Consistent fields could make publications easier to compare and reduce ambiguity in search results. |
| Evidence basis | Price and food-type needs appear in I1-S3; dietary comparison appears in I6-S2 and I6-Q4. Inconsistent free-text publications are an anticipated design risk from MS4 PAS 7. |
| Field | Description |
|---|---|
| Problem | Students seek reassurance before choosing unfamiliar establishments. A publication alone may not provide enough confidence that its information matches what they will find. |
| Alternatives | Consult friends and external reviews, as described in the interviews; moderate publications before displaying them; or collect confirmations from students after their visits. |
| Solution hypothesis | Provide a menu-information accuracy score based on recent post-visit confirmations. Show the number of confirmations supporting it and display “Insufficient confirmations” for establishments without enough evidence. |
| Rationale | Feedback about whether publications matched visitors' experiences could help students assess information reliability. The score would describe menu-information accuracy, separately from food quality. |
| Evidence basis | Allison described consulting reviews, videos, comments, and recommendations (I3-S4). These findings support the need for confidence; the scoring mechanism is the hypothesis proposed in MS4 PAS 8. |
| Field | Description |
|---|---|
| Problem | A student consulting the feed during a short break may encounter a slow or unavailable connection. Failure to retrieve publications could prevent comparison when the information is needed. |
| Alternatives | Require an active connection and display an error; retry requests until connectivity returns; or display a locally stored copy of the last successfully loaded feed. |
| Solution hypothesis | Store the last successfully retrieved feed and display it during connectivity interruptions. Show its retrieval time, hide publications whose validity windows have ended, and refresh the information when connectivity returns. |
| Rationale | A dated local copy could preserve access to useful information during an interruption. Its displayed age helps students assess how current it is. |
| Evidence basis | Contextual design hypothesis from MS4 PAS 9. Network congestion, switching conditions, and their frequency have not been measured. Cached publications may have changed since retrieval even if their validity windows remain open. |
| Field | Description |
|---|---|
| Problem | A student could select an establishment that matches their food preferences and budget but arrive with a payment method the establishment does not accept. |
| Alternatives | Check accepted methods on arrival; consult information reported by previous visitors; or obtain the information directly from establishments through their profiles. |
| Solution hypothesis | Include accepted payment methods in the establishment profile, display them with menu publications, and support filtering by payment method. Allow establishments to update the field and students to report discrepancies. |
| Rationale | Making payment information available before travelling could help students identify another practical constraint during comparison. |
| Evidence basis | Anticipated compatibility risk from MS4 PAS 10. The existing food-related interviews do not establish the prevalence of payment restrictions or their impact. This hypothesis requires further validation. |
Research references
- Interview 1 — Cristal: conducted by Juan Esteban Rojas Castañeda.
- Interview 3 — Allison: conducted by Kevin Alvarez.
- Interview 6 — Santiago: conducted by Camilo Molina.
- Evidence codes preserve the identifiers used in the previous deliverables.
Establishment staff. They publish menus mid-shift, usually with one hand free and no training on the app. That rules out any onboarding flow or multi-step form: the publish screen has to fit on a single view, ask only for what the Menu Publications Service needs, and let a staff member go live with one tap.
Students on a short break. They only have a few seconds of attention between classes to decide where to eat. Filters need to sit on the screen as tappable chips instead of a settings menu, and the feed itself has to be scannable at a glance rather than force the student to open each post to compare it.
Campus connectivity. Wifi and cellular signal drop out inside certain buildings and stairwells. The app can't assume a live connection every time it opens, so it keeps a local cache of the last-viewed feed and the student's last-used filters, so browsing keeps working the moment signal returns, even mid-session.
Denied permissions. Students can decline location or camera access. Without location, the feed falls back to a full list instead of one sorted by distance. Without camera access, a student can still file a "this post is outdated" report, just without a photo attached.
Clock reliability. An establishment's device clock can be wrong or drift from the server's. Since the feed depends on comparing a post's timestamp to the current time, expiration can't run off whatever time the establishment's phone reports. The Expiration Engine treats the client's timestamp as informational only and computes expiration against server time.
Traffic pattern. Posting and reading both spike around the class-break windows described above, not evenly through the day. The Menu Publications and Expiration services need to be sized for that burst, or the feed lags right when the most students are checking it.
Authors: Juan Jose Murillo Aristizabal
Description: Alex is a research-based composite persona representing an undergraduate student who searches for food near campus during short breaks. Alex wants to explore new establishments but needs trustworthy information about price, food type, walking time, service speed, and the exact entrance. When this information is incomplete, Alex usually returns to a familiar option.
Evidence base: This persona was developed from Interview 1 (Cristal), Interview 3 (Allison), Journey Map 1 — Discovering Food Options Near Campus, and Empathy Map 1 — The Time-Squeezed Explorer. The main evidence includes reliance on friends, fragmented information sources, limited break time, relevant comparison criteria, and difficulty locating hidden establishments.
Description: Diego is a composite persona built from Interview 6. He is an undergraduate student with a one-hour midday break and a tight budget who decides where to eat on foot. He can already name the places around him, but not the details that would let him choose between them: line length, today's price, or whether a place is even open. Without that information, he tends to end up wherever is easiest to reach instead of what he actually wants.
Evidence base: This persona was developed from Interview 6 and Empathy Map 5, The Between-Buildings Improviser. The main evidence includes waiting time as a decisive factor, a reliable off-campus vendor absent from any listing, dietary uncertainty as a real constraint, and the drop in options once everything nearby closes.
Description: Don Álvaro is an analytics persona representing the owner-operator of a small food establishment near campus. He runs the business himself, serves during peak hours, and has no staff dedicated to marketing or digital tools. He would publish a daily menu if it took under a minute, but he will stop if he cannot tell whether anyone saw it. What he wants from UniEat is not a report but an answer to a simple question: did posting today bring anyone in?
Data needs: Impressions, detail openings and student-reported arrivals per publication, each with a stated definition; comparison across his own posts over time; and the publication-time windows that attracted the most attention in his area.
Evidence base: This persona is a design hypothesis rather than a research finding. It was constructed from PAS-04 (owner participation depends on visible results), the business-model proposal in §1.6, and BQ-14 (posting-time guidance). No establishment owners were interviewed during MS2–MS4, so his motivations, willingness to publish daily, and willingness to pay for advanced analytics all remain unvalidated. Interviewing owners is a pending research task recorded in §12.3.
Design implication: Metrics must be labelled as application interactions and reported visits, never as sales. The free basic dashboard exists to sustain publishing behaviour; the paid tier must add analysis beyond it rather than withhold the basics.
The five maps below were produced in MS3 and are reproduced here with three changes: an explicit source matrix, a text transcription of the four quadrants of each map, and the removal of solution assumptions from Map 4. Each map states the interview it rests on and the team member who built it.
Every map follows the required four-quadrant structure — Thinks, Sees, Feels, Does — and describes a prospective user of UniEat deciding where to eat near campus.
| Map | Prospective user | Primary evidence | Secondary evidence | Author |
|---|---|---|---|---|
| 1 — The Time-Squeezed Explorer | Student deciding during a short break | Interview 1 (Cristal) | Interview 3 (Allison), Journey Map 1 | Juan Esteban Rojas Castañeda |
| 2 — The Habit Loyalist | Student who defaults to the same establishment | Interview 1 (Cristal) | — | Juan Esteban Rojas Castañeda |
| 3 — The Diligent Verifier | Student who researches but cannot find the entrance | Interview 3 (Allison) | — | Juan Esteban Rojas Castañeda |
| 4 — The Constrained Comparer | Student comparing options under several simultaneous constraints | Interview 6 (Santiago) | Interview 1, Interview 3 | Juan Esteban Rojas Castañeda |
| 5 — The Between-Buildings Improviser | Student with a one-hour break deciding on foot | Interview 6 (Santiago) | — | Camilo Andres Molina Plata |
Interviewers. Interview 1 was conducted by Juan Esteban Rojas Castañeda, Interview 3 by Kevin Alvarez, and Interview 6 by Camilo Molina. Full transcripts and situation codes are linked in §12.1.
Limitation. The five maps rest on three interviews. MS2 produced five interviews, but only two of them (1 and 3) addressed food options near campus, so Interview 6 was conducted during MS3 to widen the base. Maps 1 to 3 still draw on Interviews 1 and 3, and Maps 4 and 5 draw on Interview 6.
This means the maps represent three documented participants rather than three independently sampled user segments. They are useful for identifying distinct decision situations, not for establishing how common each situation is across the student population. Widening the evidence base with additional food-focused interviews is a pending research task recorded in §12.3.
About the transcriptions. The image is the artifact of record for each map. The tables below transcribe its four quadrants so the content stays readable regardless of image rendering, and so each entry can be traced to an evidence code.
"Can I make it there and back before my next class?"
Prospective user: A student deciding where to eat during a short break between classes. Evidence base: Interview 1 (Cristal), Interview 3 (Allison), Journey Map 1. Author: Juan Esteban Rojas Castañeda.
| Quadrant | Content | Evidence |
|---|---|---|
| Thinks | Whether the walk, the queue and the meal fit inside the break; whether an unfamiliar place is worth the risk of running out of time. |
I1-Q5, I1-S2
|
| Sees | Classmates mentioning places they have tried; Google results, TikTok content and comments; establishments she walks past without knowing their prices. |
I1-S1, I3-S2, I3-S4
|
| Feels | Time pressure during the break, and reluctance to spend it on a place that may not fit her budget or schedule. |
I1-S3, I3-S1
|
| Does | Asks classmates, estimates the distance, and returns to a place she already knows when the alternatives are unclear. |
I1-S1, I1-S3, I1-S2
|
Interpretation
- Main insight: the budget that binds this user is made of both money and minutes. Knowing that an establishment exists is not sufficient; the information must allow her to compare it and reach the right entrance inside the break.
- Connection to the selected problem: the information she needs is spread across classmates, Google, TikTok and physical exploration, and none of those sources reliably delivers it at the moment of deciding.
"I just go where I already know."
Prospective user: A student who defaults to the same establishment rather than take on the uncertainty of an unfamiliar one. Evidence base: Interview 1 (Cristal). Author: Juan Esteban Rojas Castañeda.
| Quadrant | Content | Evidence |
|---|---|---|
| Thinks | She already knows what the usual place sells, what it costs and how far it is; an unfamiliar place offers none of that certainty. | I1-S3 |
| Sees | The same small set of establishments she has already used; no place where the alternatives appear side by side. | I1-S2 |
| Feels | Comfortable with the known option and unwilling to spend a break resolving uncertainty. | I1-S2 |
| Does | Returns to her usual establishment whenever she does not know the alternatives. | I1-S2 |
Interpretation
-
Main insight: the loyalty is to certainty rather than to the establishment. Price, quality and distance are already known there, which makes the familiar option win by default (
I1-S2,I1-S3). - Connection to the selected problem: repetition here follows from missing information about the alternatives, not from a stated preference.
"I research it, and I still can't find the door."
Prospective user: A student willing to research thoroughly, blocked at the final step of physically locating the establishment. Evidence base: Interview 3 (Allison). Author: Juan Esteban Rojas Castañeda.
| Quadrant | Content | Evidence |
|---|---|---|
| Thinks | Whether the place is good, fast and affordable enough to justify the trip, based on what other people report about it. |
I3-S1, I3-S4
|
| Sees | Recommendations from friends, reviews, videos and other users' comments; on arrival, a facade, sign and entrance that are hard to recognize. |
I3-S2, I3-S4, I3-S3
|
| Feels | Confident after researching, then frustrated when the research does not translate into finding the place. | I3-S3 |
| Does | Consults friends and online sources before going, then walks around the area looking for the entrance. |
I3-S2, I3-S3
|
Interpretation
-
Main insight: the research succeeds and the arrival fails. The gap is not information about the establishment but recognition of it on the street (
I3-S3,I3-S4). - Connection to the selected problem: a recommendation that cannot be acted on still costs the student part of the break.
"Too many things have to be true at once."
Prospective user: A student comparing food options that must satisfy several constraints at the same time — budget, dietary requirement and available time — often on behalf of a group.
Evidence base: Interview 6 (Santiago), situation I6-S2; supported by the price and proximity criteria reported in Interviews 1 and 3.
Author: Juan Esteban Rojas Castañeda.
| Quadrant | Content | Evidence |
|---|---|---|
| Thinks | Whether an option fits everyone's budget at the end of the month and whether any of the dishes are actually vegetarian rather than merely labelled as such. |
I6-S2, I6-Q4, I6-Q9
|
| Sees | Several establishments, each showing only part of what he needs; no source where current prices and dietary information appear together. | I6-Q4 |
| Feels | That the comparison is consuming the break it was supposed to protect, with four people waiting on the outcome. | I6-S2 |
| Does | Walks between establishments outside campus and cafeterías in other buildings for about twenty minutes, then settles on the single option that satisfies everyone. | I6-S2 |
Interpretation
-
Main insight: the difficulty is not the number of establishments but the cost of checking several partial sources against several constraints at once. Each constraint is easy alone; together they can only be resolved on foot (
I6-S2,I6-Q4). - Connection to the selected problem: the information required to reconcile budget and dietary requirements exists, but not in a form reachable during the break in which the decision has to be made.
Revision note. In MS3 this map was titled The Overwhelmed Comparer and was grounded partly in the "Lunch roulette" brainstorming idea, and its interpretation prescribed filters and quick-decision tools. Both were solution assumptions rather than research findings. The map is now grounded in
I6-S2, and the corresponding design responses are stated as hypotheses in §2 (PAS-05, PAS-07) rather than inside the empathy map.
"I could have known this before leaving the classroom."
Prospective user: A student with a one-hour midday break and a tight budget, deciding on foot between campus and street options. Evidence base: Interview 6 (Santiago). Author: Camilo Andres Molina Plata.
| Quadrant | Content | Evidence |
|---|---|---|
| Thinks | Whether he can eat and return within the hour; how long the line will be at 12:30; whether anything is still open in the evening. |
I6-Q2, I6-S3
|
| Sees | The queue at the establishment he intended to use; a street vendor on the route to his next class; no listing anywhere that covers either. |
I6-S1, I6-Q3
|
| Feels | That the decision is being made for him by whatever happens to be on the way. | I6-S1 |
| Does | Turns around when the line is long and buys from the vendor on his route; falls back to vending machines after 5:00 pm; enters new establishments only when somebody takes him. |
I6-S1, I6-S3, I6-S4
|
Interpretation
- Main insight: he can name the places around him; what he cannot know is anything that would let him choose between them. Line length, today's menu, the real price and whether a place is open are discovered on foot, inside the same hour he is trying to eat in.
-
Connection to the selected problem: asked what would make finding food easier, he described current menus, current prices and current availability without being prompted with any solution (
I6-Q9). This map extends the problem beyond Interviews 1 and 3 with waiting time as a decisive criterion, street vendors absent from every platform, dietary needs as a concrete group constraint, and the collapse of options after 5:00 pm.
Empathy maps describe observed situations. The design responses they motivate are stated as hypotheses in §2 and evaluated through the questions in §6.
| Map | Situation described | Persona | Design hypothesis it informs |
|---|---|---|---|
| 1 | Deciding under a fixed time limit with scattered information | Alex | PAS-05 (BQ-03) |
| 2 | Falling back on the familiar option when alternatives are unknown | Alex | PAS-05, PAS-08 |
| 3 | Researching successfully but failing to recognize the entrance | Alex | PAS-03 (BQ-05, BQ-10) |
| 4 | Reconciling budget, dietary requirement and time across partial sources | Diego | PAS-05, PAS-07 (BQ-03, BQ-09) |
| 5 | Deciding on foot without current menu, price or queue information | Diego | PAS-01, PAS-02, BQ-06 |
The following fourteen questions refine the ten questions from [MS4][bq-ms4] and add four proposals for Sprint 1. Their distribution is 2 Type 1, 4 Type 2, 4 Type 3, 2 Type 4, and 2 Type 5. Each question is counted once and keeps a stable identifier for the VD Map.
The fifth category is called Type* in the [course book][bq-taxonomy]. This section labels it Type 5 (Type)* to match the Sprint 1 guide. The [classification guide][bq-classification] distinguishes information delivered directly to users from analysis used to decide changes to features.
These are proposed analytics questions. The observation periods and controlled pilots describe future evaluation; no results or completed experiments are claimed.
These answers support technical diagnosis by the development team.
| Field | Description |
|---|---|
| Question | Over the last seven days, which combinations of connection type, device model, and OS version had the highest feed-loading failure rates and 95th-percentile request-to-render times, broken down by hour? |
| Answer and use | A technical breakdown for prioritizing loading failures and slow rendering. Successfully displayed empty results are distinguished from technical failures. |
| Required data | Request and render timestamps, technical outcomes, error types, connection type, device model, OS version, and session identifiers. |
| Origin | Refines Samuel David Rozen Mogollon's Type 1 question from MS4. |
| Field | Description |
|---|---|
| Question | Over the last seven days, which screens and preceding actions had the highest crash rates per 1,000 sessions visiting those screens, segmented by device model, OS version, and app version? |
| Answer and use | A ranked list of technical failure points to investigate and fix. |
| Required data | Crash records, last recorded screen and action, screen visits, session identifiers, device model, OS version, and app version. |
| Origin | Additional Sprint 1 proposal extending the app telemetry concerns documented in MS4. |
Each answer is information shown to a particular user during an interaction with UniEat.
| Field | Description |
|---|---|
| Question | Which currently valid menu publications should appear first for a student, given their selected budget, dietary requirements, location or selected area, and available minutes? |
| Answer and use | A ranked feed explaining the constraints each option matches and any missing information. Time compatibility is an estimate. |
| Required data | Current publications, prices, dietary declarations, coordinates, validity windows, available travel and waiting estimates, and the student's selected constraints. |
| Origin | Refines Kevin David Alvarez Romero's Type 2 question; PAS-05. |
| Field | Description |
|---|---|
| Question | What validity and reported-change status should UniEat show for each publication a student is consulting, based on its publication time, expiry, latest confirmed updates, and unresolved discrepancy reports? |
| Answer and use | Publication age, expiry status, and clearly identified reported changes. Expired publications leave the active feed; unresolved reports remain distinguishable from confirmed updates. |
| Required data | Publication and expiry timestamps, update history, report categories, report timestamps, and resolution status. |
| Origin | Reformulates Juan Esteban Rojas Castañeda's freshness question to provide a direct user-facing answer; PAS-01. |
| Field | Description |
|---|---|
| Question | For the establishment a student has selected, which entrance and location references are currently available, and which need an uncertainty warning because details are missing or location discrepancies remain unresolved? |
| Answer and use | A location card presenting the available pin, storefront photograph, entrance description, and relevant missing-information or reported-discrepancy notices. |
| Required data | Selected establishment, profile references, update timestamps, and location-report resolution status. |
| Origin | Reformulates Camilo Andres Molina Plata's first location-information question as guidance delivered to the student; PAS-03. |
| Field | Description |
|---|---|
| Question | What waiting-time estimate can UniEat show for the student's selected establishment at the current time, considering recent reports, comparable historical reports, and their age and quantity? |
| Answer and use | An estimated wait with information freshness, or an insufficient-information state, to support the student's decision before travelling. |
| Required data | Establishment identifier, reported waiting minutes, report timestamps, current time, and historical waiting reports. |
| Origin | Additional Sprint 1 proposal based on PAS-06 and Interview 6. |
These answers help the team decide whether to retain, modify, or add a capability. The variants below are proposed pilot conditions.
| Field | Description |
|---|---|
| Question | In a controlled pilot, does adding a “still accurate” confirmation option produce a higher reported menu-match rate than an outdated-report-only variant, using the same post-visit assessment in both groups? |
| Answer and use | Compare matching-menu reports among completed assessments, alongside assessment response rates, to decide whether to retain or revise positive confirmations. |
| Required data | Assigned variant, publication selections, positive confirmations, discrepancy reports, and the common post-visit assessment responses. |
| Origin | Refines Juan Esteban Rojas Castañeda's Type 3 question; PAS-01 and PAS-08. |
| Field | Description |
|---|---|
| Question | In a controlled pilot, does displaying a waiting-time indicator reduce the share of menu selections followed within ten minutes by a “line too long” report or selection of a different establishment, compared with a variant without the indicator? |
| Answer and use | Compare the defined follow-up event rate to decide whether to retain or redesign the indicator. |
| Required data | Assigned variant, indicator exposure, initial and subsequent selections, establishment identifiers, long-line reports, and timestamps. |
| Origin | Refines Kevin David Alvarez Romero's Type 3 question; PAS-06. |
| Field | Description |
|---|---|
| Question | In a controlled pilot, does a structured menu form increase the share of publications usable by category, price, and dietary filters without reducing publication completion, compared with a free-text form? |
| Answer and use | Compare filterable-publication and publication-completion rates to decide whether to retain or simplify the structured form. Unknown dietary information remains explicitly unknown. |
| Required data | Assigned form variant, form starts, completed publications, field values, and the same filterability criteria applied to both variants. |
| Origin | Refines Juan Jose Murillo Aristizabal's Type 3 question; PAS-07. |
| Field | Description |
|---|---|
| Question | For establishments with location and storefront references available, does showing the pin and photograph together with the selected menu increase reported-arrival rates and reduce “couldn't find it” report rates compared with an address-only presentation in a controlled pilot? |
| Answer and use | Compare both rates per eligible selection to decide how entrance information should be presented. |
| Required data | Assigned presentation variant, available profile references, menu selections, student-reported arrivals, and location-failure reports. |
| Origin | Reformulates Camilo Andres Molina Plata's second location-information question as Type 3; PAS-03. |
These answers support proposed aggregate reports for external food businesses. Their commercial value and customers' willingness to pay remain hypotheses from Section 1.6.
| Field | Description |
|---|---|
| Question | Over the last 28 days, which food-category and price-range combinations attracted the highest menu-selection rates among UniEat users, segmented by campus area and time of day? |
| Answer and use | An aggregate report that UniEat could offer to food businesses evaluating menu positioning or a potential location. Include exposure counts and rates rather than raw popularity alone. |
| Required data | Publication category and price, feed impressions, selections, establishment area, and timestamps. |
| Origin | Refines Juan Jose Murillo Aristizabal's Type 4 question from MS4. |
| Field | Description |
|---|---|
| Question | Over the last 28 days, which combinations of selected area, time period, food category, and budget had the highest proportion of searches returning no valid publications in UniEat? |
| Answer and use | An aggregate feed-coverage report for external establishments considering which offers to publish. Zero results indicate a gap in UniEat's available information, not proof that food options do not exist in the area. |
| Required data | Search timestamps, selected area and filters, valid-result counts, and publication availability at query time. |
| Origin | Additional Sprint 1 proposal extending the aggregate demand-information concept in MS4 and Section 1.6. |
These questions have two explicitly identified purposes. They are counted only in this category.
| Field | Description |
|---|---|
| Question | In a controlled pilot, how do feed-rendering time and the share of sessions ending without a menu selection differ between cache-enabled and online-only variants under comparable connection conditions? |
| Combined types | Type 1: diagnose technical loading behavior. Type 3: decide whether to retain or revise local caching. |
| Answer and use | A technical and interaction-outcome comparison supporting the cache decision. Analyze connection conditions and whether an eligible cached copy existed. |
| Required data | Assigned variant, connection type, request and render timestamps, technical outcomes, cache availability and age, and session selection outcomes. |
| Origin | Refines Samuel David Rozen Mogollon's combined question; PAS-09. Aggregate abandonment analysis is not counted as a Type 2 component. |
| Field | Description |
|---|---|
| Question | Over the last 28 days, which publication-time windows had the highest detail-open rates during each post's first hour, for individual establishments and at campus-area level, to inform owners' posting schedules and aggregate commercial benchmarks? |
| Combined types | Type 2: show establishment owners posting-time guidance in their app. Type 4: offer aggregate area-level timing patterns in the proposed paid reports for external food businesses. |
| Answer and use | Owner-specific timing guidance and an aggregate benchmark derived from the same analysis. Display sample counts and describe the observed association without promising that changing posting time will improve results. |
| Required data | Publication timestamps, impressions and detail openings within the first hour, establishment identifiers, and campus areas. |
| Origin | Additional Sprint 1 proposal extending PAS-02, PAS-04, and the business-model hypothesis in Section 1.6. |
- Impression: a publication displayed to a student. Selection and detail-open rates use distinct session-publication pairs with the relevant action divided by distinct exposed pairs in the same analysis window.
- Selection: an explicit choice of an establishment or menu, recorded separately from opening its details.
- Reported arrival: a student's arrival confirmation. Commercial reports must describe it as a reported visit.
- Pilot comparisons: use assigned variants, consistent eligibility rules, and the same outcome definitions. Include group sizes and missing-response rates when interpreting results.
- Unknown information: missing reports or a zero denominator produce an insufficient-information result. Unknown dietary information cannot establish that a dietary requirement is met.
- Commercial outputs: report aggregated counts and rates. The proposed recipients and uses do not demonstrate willingness to pay or represent the entire campus food market.
- VD Map: Section 7 must retain identifiers BQ-01 to BQ-14 and map each question to its data, processing, and output.
Original / full-resolution file: https://drive.google.com/file/d/1rPdgjpztV61G0HJKC3Q9rKHjgCTarEkS/view?usp=sharing
The following sources are proposed components of the solution's data collection. Operational records and pilot results are not presented as existing datasets.
| ID | Source and acquisition | Required information |
|---|---|---|
| D01 | Mobile loading telemetry, collected through application instrumentation. | Load identifier, session identifier, feed-load start, network-request start, render completion, technical outcome, connection type, device model, OS version, and app version. |
| D02 | Crash and navigation records, collected through mobile instrumentation. | Crash identifier, timestamp, session, last recorded screen and action, screen visits, device model, OS version, and app version. |
| D03 | Menu publication database and version history, populated through establishment publishing and updates. | Publication and version identifiers, establishment, dishes, category, declared price or range, dietary information, publication time, expiry, withdrawal status, and update history. |
| D04 | Establishment profiles and their update history. | Establishment identifier, campus area, coordinates, storefront photograph, entrance description, opening information, accepted payment methods, and update timestamps. |
| D05 | Current student context, supplied through filters and optional device location. | Budget, dietary requirements, available minutes, selected area or permitted location, and the time of the request. |
| D06 | Reports, confirmations, and common pilot assessments submitted through UniEat. | Report identifier, publication/version or establishment, report category, timestamp, resolution status, positive confirmations, assessment eligibility, invitations, and responses. |
| D07 | Student waiting reports stored by the proposed waiting-information service. | Report identifier, establishment, reported waiting minutes, observation timestamp, and submission timestamp. |
| D08 | Interaction and search events recorded by the application and backend. | Session and event identifiers, impressions, detail openings, selections, reported arrivals, search filters, query outcome, valid-result count at query time, timestamps, and relevant publication versions. |
| D09 | Pilot assignment and exposure records. | Experiment identifier, assignment unit, assigned variant, eligibility, assignment time, and actual exposure to the tested presentation or capability. |
| D10 | Publication-form and pilot validation records. | Form-attempt identifier, start and completion events, form variant, submitted content, field-validation results, and filterability assessment under a common rubric. |
| D11 | Local-cache instrumentation. | Whether an eligible copy existed before serving the feed, retrieval time, stored validity information, cache use, copy age, refresh attempts, and the rendering path used. |
| D12 | Proposed walking-route estimation integration. | Origin, destination, estimated walking duration and distance, response timestamp, and unavailable-route status. The provider and integration remain to be selected. |
Availability considerations
- D01–D11 can be collected through the proposed application, backend, and pilot instrumentation.
- D06 must include assessment invitations as well as responses; responses alone cannot establish an assessment response rate.
- D09 and the pilot-specific parts of D06 and D10 require explicit experimental instrumentation.
- D12 is an additional integration dependency for travel-time estimates. Until available, UniEat should identify travel-time compatibility as unknown.
- A manually selected area provides less precise context than a known origin.
- Interviews support the design choices but do not substitute for operational telemetry or pilot observations.
The processing below specifies how raw records become the information required by each visualization.
| Question / process | Processing and derived information | Visualization and recipient |
|---|---|---|
| BQ-01 / P01 | Join loading events by load identifier. For the last seven days, calculate technical failures divided by completed loading attempts and p95 request-to-render time among rendered attempts. Group by hour, connection, device, and OS. Separate successful empty-result states from failures and non-rendered attempts. | Separate heatmaps for failure rate and p95 rendering time, accompanied by attempt counts and ranked diagnostics for the development team. |
| BQ-02 / P02 | Deduplicate crash records. Group by screen, preceding action, device, OS, and app version. Divide crash count by distinct sessions visiting the corresponding screen and multiply by 1,000. Preserve an unknown category when the preceding action was not recorded. | Ranked crash-rate bars and a diagnostic table for the development team. The preceding action is an investigation clue. |
| BQ-03 / P03 | Select currently valid, non-withdrawn publications. Compare declared price and dietary information with the student's constraints. Combine location, D12 travel estimates when available, and waiting information from P06. Rank the available matches and generate explanations identifying approximate or missing information. | A personalized student feed with matching criteria and uncertainty notices. Travel plus waiting estimates must not be presented as a guaranteed total meal duration. |
| BQ-04 / P04 | Compare authoritative current time with publication and expiry timestamps. Join the relevant update history and unresolved reports. Derive publication age, expiry status, and reported-change notices, preserving the distinction between a pending report and a confirmed update. | Age and validity labels, reported-change notices, and removal of expired publications from the student's active feed. |
| BQ-05 / P05 | Retrieve references for the selected establishment. Check field availability and join unresolved location reports and confirmed profile updates. Identify which references can be shown and which missing details or reported discrepancies require a notice. | An entrance information card containing the available pin, photograph, description, and relevant notices for the student. |
| BQ-06 / P06 | Deduplicate reports and reject invalid waiting values. Group by establishment and observation period. Apply a documented freshness rule and calculate a proposed median-based estimate from eligible reports. Distinguish historical fallback estimates and retain report count and age. Return insufficient information when coverage or freshness requirements are unmet. | A waiting-time card with estimate, freshness, and source coverage, or an insufficient-information state. Freshness and coverage thresholds require validation. |
| BQ-07 / P07 | Join assigned variants, eligible invitations, and common post-visit assessments. Calculate matching-menu responses divided by completed assessments, and completed assessments divided by eligible invitations, separately for each variant. Use the same assessment and follow-up conditions in both groups. | Grouped bars for reported menu-match and assessment-response rates, with counts, supporting the team's confirmation-feature decision. |
| BQ-08 / P08 | Identify eligible initial selections with a complete ten-minute observation window. Link a long-line report or a different-establishment selection by the same student during that window. Count the combined outcome once per initial selection and divide by eligible initial selections in each variant. Separate incomplete follow-up. | Comparative event-rate bars, sample counts, and rate differences for the team's waiting-indicator decision. |
| BQ-09 / P09 | Apply the same content and filterability rubric to both publication formats. Calculate filterable publications divided by completed publications, separately by field and for all required fields. Also calculate completed publications divided by form starts. Preserve unknown dietary information explicitly. | Separate grouped charts for filterability and publication completion, supporting the decision to retain or simplify the structured form. |
| BQ-10 / P10 | Establish eligibility from available location references before showing the variant. Join selections, assigned presentation, reported arrivals, and location-failure reports. Calculate each outcome per eligible selection using consistent follow-up conditions. | Reported-arrival and location-failure rate charts with group sizes, supporting the team's entrance-presentation decision. |
| BQ-11 / P11 | Join impressions and selections to the publication version shown at the time of the event. Over 28 days, group by category, price range, area, and time period. Divide distinct exposed session-publication pairs with a selection by all distinct exposed pairs in the same group. | A category-by-price heatmap showing selection rates and exposure counts, with area and time filters, for proposed commercial reports to food businesses. |
| BQ-12 / P12 | Retain successfully executed searches and their recorded query-time result counts. Group by selected area, time period, category, and budget over 28 days. Divide zero-valid-result searches by all successful searches in each group. Exclude technical errors from the zero-result numerator. | A feed-coverage heatmap and ranked table of information gaps, with query counts, for external establishments considering which offers to publish. |
| BQ-13 / P13 | Compare assigned cache variants under comparable connection conditions. Measure rendering from a common feed-load start covering both network and cache paths. Report rendering-time distributions, non-render rates, and completed sessions without selections. Assess prior cache eligibility consistently in both groups. | Rendering-time plots alongside non-render and no-selection rates, informing technical diagnosis and the cache design decision. |
| BQ-14 / P14 | Retain publications from the 28-day analysis period whose complete first hour is observable. Deduplicate impressions and detail openings by session-publication pair within that hour. Group by publication-time window, establishment, and campus area. Calculate detail-open rates from aggregated numerators and denominators. | Two outputs: posting-time guidance inside the owner's app, and aggregate area-level timing benchmarks for the proposed commercial reports. Both show supporting counts. |
| ID | User Action | System Response | Execution Context | Author |
|---|---|---|---|---|
| FS-01 | After visiting an establishment, the student reports that a dish from the publication was unavailable or that its price differed from the one shown. | Records the report against the specific publication version, flags the publication as having a reported change pending confirmation, reduces its position in the feed, and shows the notice to other students without presenting it as a confirmed correction. | Student has just left the establishment, often on mobile data, reporting within the same break; the publication's validity window has not yet expired. | Juan Esteban Rojas Castañeda |
| FS-02 | An establishment owner opens UniEat after receiving the daily publication reminder and does not publish a menu. | Keeps the establishment visible in the feed with an explicit No menu published today status, distinct from the establishment's opening status, and sends no further reminder that day. | Owner is in service hours with no time to publish; students are browsing the same feed and must not read the absence as the establishment being closed. | Juan Esteban Rojas Castañeda |
| FS-03 | From a selected menu publication, the student opens the establishment's location card. | Displays the map pin, storefront photograph and entrance description available in the profile, each with its last update time. Explicitly labels any missing reference and any unresolved location discrepancy report. | Student on campus during a short break, walking between buildings, possibly with location permission denied (area selected manually) and on congested campus Wi-Fi. | Camilo Andres Molina Plata |
| FS-04 | An establishment owner opens the performance view for one of their publications from the last seven days. | Displays impressions, detail openings and student-reported arrivals for that publication, each accompanied by its definition, and shows an insufficient-data state where counts are too low to be meaningful. | Owner on a mobile device during or shortly after service hours, on mobile data, reviewing a publication that has already expired. | Camilo Andres Molina Plata |
| FS-05 | During a midday break, Diego opens today's feed, manually selects the campus area near his next class, sets a maximum budget of COP 15,000, selects Vegetarian for one member of his group, enters 40 available minutes, and opens one of the compatible publications. | UniEat removes expired or withdrawn publications and presents the currently valid options whose declared price and dietary information satisfy the selected constraints. It orders them using the selected area and available travel- and waiting-time estimates, explains which constraints each result matches, and labels approximate or missing information. A publication with unknown dietary information is not presented as a confirmed vegetarian match, and the applied filters remain active when Diego returns to the feed. | Diego and three classmates are deciding where to eat during their midday break; one classmate is vegetarian. Precise-location permission is unavailable, so Diego selects the area manually. Current publications contain both complete and incomplete travel, dietary, and waiting information. | Kevin David Alvarez Romero |
| FS-06 | From a current menu publication, Diego opens the establishment's waiting-time information before deciding whether to walk there. | UniEat shows the supported waiting-time estimate together with its freshness and number of eligible reports, clearly identifies it as an estimate, and keeps the menu and location actions available. If the available reports do not satisfy the configured coverage rule, it displays Insufficient information instead of producing an unsupported numeric value. | Diego is choosing lunch before leaving campus and has limited time before his next class. The selected menu publication is still valid, but the quantity and age of recent waiting reports may vary. Historical reports from comparable periods may be available; the estimation method remains a design hypothesis to validate. | Kevin David Alvarez Romero |
| FS-07 | An establishment owner publishes the day's menu using the structured form, filling dish name, category and price, and marks the dietary information for one dish as unknown. | Validates the required fields, stores each value in its own field so filters and comparisons can use it, publishes with a timestamp and validity window, and preserves the unknown dietary value explicitly rather than defaulting it to any dietary category. | Owner publishing mid-shift on a phone, with one hand free and limited time; the form must be completable in a single view. | Juan Jose Murillo Aristizabal |
| FS-08 | After visiting an establishment, the student answers the post-visit assessment confirming whether the published menu matched what they found. | Records the confirmation against the publication version, updates the establishment's menu-information accuracy score, and displays the number of recent confirmations supporting it. Where confirmations are too few, it shows Insufficient confirmations instead of a score. | Student responding shortly after the visit; the establishment may be new to UniEat and have little or no confirmation history. | Juan Jose Murillo Aristizabal |
| FS-09 | The student opens the feed inside a building where the connection drops, and no request completes. | Displays the last successfully retrieved feed together with its retrieval time, hides publications whose validity windows have ended since retrieval, indicates that the information is not live, and refreshes automatically when connectivity returns. | Student on a short break inside a building with unreliable Wi-Fi and weak cellular signal; the cached copy may be minutes or hours old. | Samuel David Rozen Mogollon |
| FS-10 | Before travelling, the student filters the feed by accepted payment method and opens a matching publication. | Shows the payment methods declared in the establishment profile alongside the menu, with their last update time, excludes establishments that have not declared the selected method, and labels establishments whose payment information is missing rather than assuming they accept it. | Student carrying only one payment method, deciding during a break; some profiles have complete payment information and others have none. | Samuel David Rozen Mogollon |
- Quality attributes: Information correctness, usability.
- App status and context: A publication is inside its validity window and visible in the feed to several students.
- Changes in the context: A student reports that a dish is unavailable, while the establishment has not confirmed or corrected the publication.
- System reaction: Within 5 seconds of the report, the affected publication shows a pending-report notice and drops in feed position. The notice is visually distinct from a confirmed update, the original declared information remains visible, and the publication is not removed on the strength of a single unconfirmed report.
- Author: Juan Esteban Rojas Castañeda
- Quality attributes: Information correctness, usability.
- App status and context: The student is browsing today's feed; a registered establishment has not published a menu.
- Changes in the context: The student filters by an area where several registered establishments have not published.
- System reaction: Each unpublished establishment appears with an explicit "No menu published today" status rather than being omitted, and its opening status is presented separately or marked unknown. The feed never implies that no food options exist in the area.
- Author: Juan Esteban Rojas Castañeda
- Quality attributes: Usability, information correctness, availability.
- App status and context: The student has selected a publication and requests entrance guidance. The establishment profile contains a map pin but no storefront photograph.
- Changes in the context: A location discrepancy reported by a previous student remains unresolved.
- System reaction: Renders the available references within 2 seconds, states which reference is missing instead of leaving a blank field, and displays the pending-report notice clearly distinguished from a confirmed correction.
- Author: Camilo Andres Molina Plata
- Quality attributes: Performance, availability, information correctness.
- App status and context: The owner opens the publication performance view over an intermittent mobile connection, with 28 days of publication history stored.
- Changes in the context: The metrics request times out before completing.
- System reaction: Displays the last successfully retrieved figures together with their retrieval time, never a partial or silently stale total, and refreshes automatically when connectivity returns.
- Author: Camilo Andres Molina Plata
- Quality attributes: Usability, performance, information correctness.
- App status and context: Diego has opened today's feed during a midday break. Valid publications are loaded, precise-location permission is unavailable, and he needs to consider a COP 15,000 budget, a vegetarian requirement, a manually selected campus area, and 40 available minutes.
- Changes in the context: While walking between buildings and using the phone with one hand, Diego applies the four constraints, opens a compatible publication, and returns to the feed.
- System reaction: Under nominal connectivity, the application updates the eligible results within 2 seconds, keeps all active constraints visible, and preserves the filters and scroll position when Diego returns. It distinguishes exact matches, estimates, and missing information. If no publication satisfies all mandatory constraints, it displays an explicit zero-results state and does not silently relax the budget or dietary requirement.
- Author: Kevin David Alvarez Romero
- Quality attributes: Information correctness, usability, availability.
- App status and context: Diego is viewing a valid menu publication whose waiting-time card currently contains an estimate based on eligible recent reports and comparable historical information.
- Changes in the context: The reports supporting the estimate pass the configured freshness limit, leaving insufficient evidence to maintain the previously displayed value.
- System reaction: No later than 1 second after receiving the refreshed report status, the application replaces the unsupported numeric estimate with Insufficient information, shows the age and number of eligible reports, and never presents the previous value as current. The menu and location information remain available. When sufficient eligible reports become available again, the estimate is recalculated and displayed with its new update time.
- Author: Kevin David Alvarez Romero
- Quality attributes: Usability, information correctness, performance.
- App status and context: An owner opens the publication form during service hours to post the day's menu.
- Changes in the context: The owner leaves one dish's dietary information unspecified and submits.
- System reaction: The form accepts the submission with dietary information recorded as unknown, never inferring a dietary category, and publishes within 3 seconds under nominal connectivity. Dishes with unknown dietary information are excluded from dietary filter results rather than returned as matches.
- Author: Juan Jose Murillo Aristizabal
- Quality attributes: Information correctness, usability.
- App status and context: A student opens the profile of an establishment recently added to UniEat.
- Changes in the context: The establishment has fewer post-visit confirmations than the configured minimum.
- System reaction: The application displays "Insufficient confirmations" instead of a numeric score, states the number of confirmations held, and does not present the absence of evidence as a negative rating. The score, when shown, is labelled as menu-information accuracy and never as food quality.
- Author: Juan Jose Murillo Aristizabal
- Quality attributes: Availability, information correctness, performance.
- App status and context: The student opens the feed inside a building; a locally stored copy from an earlier session is available.
- Changes in the context: The network request fails or does not complete within the configured timeout.
- System reaction: Within 2 seconds the application renders the stored copy, shows its retrieval time, excludes publications whose validity windows have ended, and marks the view as not live. It retries in the background and replaces the view when a fresh feed arrives. It never presents cached content as current.
- Author: Samuel David Rozen Mogollon
- Quality attributes: Information correctness, usability.
- App status and context: The student has filtered the feed by a specific accepted payment method.
- Changes in the context: Some matching establishments have not declared their accepted payment methods.
- System reaction: Establishments with no declared payment information are excluded from the filtered results rather than assumed compatible. When such an establishment is opened directly, the profile states that payment information is missing and offers the option to report it, with the last profile update time shown.
- Author: Samuel David Rozen Mogollon
Video link: https://drive.google.com/file/d/1JFhH1PLw7c0KhmAYRgxePxNDXZvkWbv-/view?usp=sharing
Duration: 7:54 minutes
Participants: Juan Esteban Rojas Castañeda, Camilo Andres Molina Plata, Kevin David Alvarez Romero, Juan Jose Murillo Aristizabal, Samuel David Rozen Mogollon
The video addresses five ethical dimensions of UniEat, each linked to a design decision documented in this report.
Data privacy and proportionality. UniEat processes optional location, dietary filters, searches, selections, reported arrivals and telemetry (D01–D12). Combined, these records could reveal a student's routines and restrictions. Commitments: collect only what a defined purpose requires, keep the core feed usable without location or camera permissions, and restrict commercial reports (BQ-11, BQ-12) to aggregated groups, excluding individual histories and very small groups. A selection inside UniEat is not a purchase and does not represent total market demand.
Information accuracy and prevention of harm. Menus, prices, payment methods and waiting conditions change. Incorrect dietary information is the most serious case, since students may rely on it for health-related decisions. Commitments: display publication time, declared source and update history (BQ-04); show unresolved reports as pending rather than confirmed corrections; present waiting times as estimates with their freshness and coverage, or as insufficient information (BQ-06); and never present establishment-declared dietary tags as an allergen-safety guarantee.
Fairness in ranking and accessibility. Ordering menus redistributes visibility, and establishments with little data — new, small or informal vendors — could be penalised if missing information is read as poor quality. Commitments: explain matching criteria, label missing data as unknown, audit impressions and selections for repeated disparities, and ensure the proposed paid tier never sells position in the student feed. Accessibility covers readable text, sufficient contrast and textual alternatives for photographs and map content.
Inclusion and social, commercial and environmental effects. Students with older devices, unstable connectivity or limited data, and owners with little time for digital publishing, could be excluded. Commitments: manual area selection, a dated cached feed during connectivity interruptions (PAS-09), a short publication form, and free basic participation. The team does not claim that UniEat reduces food waste, since the design measures neither inventory nor discarded food.
Research ethics and team responsibility. The food research rests on three interviews, which inform the design but do not represent the whole student population. Commitments: attribute each interview to its interviewer, keep participation voluntary and informed, distinguish participants' statements from team interpretations in personas and empathy maps, and present establishment willingness to publish or pay as an unvalidated hypothesis rather than a finding.
| # | Topic | Speaker |
|---|---|---|
| 1 | Introduction and solution overview | Juan Esteban Rojas Castañeda |
| 2 | Data privacy and commercial analytics | Camilo Andres Molina Plata |
| 3 | Information accuracy and prevention of harm | Juan Jose Murillo Aristizabal |
| 4 | Fairness, rankings and accessibility | Kevin David Alvarez Romero |
| 5 | Inclusion and social, commercial and environmental effects | Samuel David Rozen Mogollon |
| 6 | Ethics of research and team decision-making | Juan Esteban Rojas Castañeda |
| 7 | Closing commitments | All members |
- GitHub Project / Kanban: Sprint 1 — Solution Context and Design
- Sprint milestone: Sprint 1
- Issues: Sprint 1 issues
Work for this sprint was split by wiki section. Each section has its own issue in the Sprint 1 milestone, and the milestone tracks completion against the September 5 deadline. Since this sprint produces no code, the issues, the milestone and the wiki revision history are the record of who did what.
| Team Member | Contribution / Artifact | Evidence |
|---|---|---|
| Juan Esteban Rojas Castañeda | Interview 1 (Cristal); PAS-01, PAS-02; BQ-04, BQ-07; Empathy Maps 1–4; Personas Alex and Diego; repository administration | Issues #13, #14, #15, #16; wiki revision history §2.1, §4.1, §4.2, §5.2–§5.5 |
| Camilo Andres Molina Plata | Interview 6 (Santiago); PAS-03, PAS-04; BQ-05, BQ-10; Empathy Map 5; FS-03, FS-04; QS-03, QS-04; §10.1 and §10.2; milestone and issue setup | Issues #18, #19, #20; wiki revision history §2.2, §5.6, §8, §9, §10, §11 |
| Kevin David Alvarez Romero | Interview 3 (Allison); PAS-05, PAS-06; BQ-03, BQ-08; FS-05, FS-06; QS-05, QS-06; Context Canvas and VD Map diagrams | Issues #11, #17; wiki revision history §2.3, §3.1, §7.1, §8, §9 |
| Juan Jose Murillo Aristizabal | PAS-07, PAS-08; BQ-09, BQ-11; §3.2 Contextual constraints; §12.3 feedback log | Issues #12, #20; wiki revision history §2.4, §3.2, §12.3 |
| Samuel David Rozen Mogollon | PAS-09, PAS-10; BQ-01, BQ-13; FS-09, FS-10; QS-09, QS-10 | Issues #15, #16; wiki revision history §2.5, §6.1, §6.5, §8, §9 |
-
Task tracking. Each wiki section has its own issue in the
Sprint 1milestone. The milestone page shows open and closed issues against the September 5 deadline. - Wiki integration. All artifacts are integrated into a single Sprint 1 page. The GitHub wiki revision history records each edit with its author and timestamp.
- Traceable authorship. Empathy maps (§5.1), functional scenarios (§8) and quality scenarios (§9) state their author explicitly, so each contribution can be attributed to a named member and reviewed against the evidence codes in §12.1.
- Feedback integration. Corrections raised in MS2–MS4 were resolved and recorded in §12.3, with the affected section listed for each change.
| Source | Feedback | Change Made | Updated Section / Evidence |
|---|---|---|---|
| MS2 | Interview 4 covered a problem not in the selected list, and no interview covered "Campus navigation for newcomers" | Interviews unrelated to the selected food-discovery problem were dropped from the research basis; Interview 6 (Santiago) was added in MS3 as a third interview aligned with the single selected problem, and the reduced evidence base is now stated as an explicit limitation | §1.2, §5.1 |
| MS2 | Several Situations "How" statements proposed app solutions instead of describing observed behavior | Findings are now cited only through evidence codes rather than reproduced as prose; empathy map interpretations separate observed behavior from design responses, with the responses relocated to the PAS hypotheses | §2, §5.2–§5.6 |
| MS2 | State who made every interview, graph, etc. instead of just "Interview 1, 2, 3, 4" | Every interview, persona, and empathy map now names its interviewer or author directly in the text | §1.2, §4.1–§4.2, §5.1 |
| MS2 | Include an index in the wiki instead of leaving navigation to the pages section | Added a numbered Table of Contents at the top of the document linking to all 12 sections | Table of Contents |
| MS3 | Empathy Map 4 incorporated solution assumptions | The map was re-grounded in I6-S2; the solution statements were removed and relocated to PAS-05 and PAS-07 |
§5.5, §2.3, §2.4 |
| MS3 | Empathy maps reuse the same interviews | The source matrix is now explicit, Map 4 was re-anchored to Interview 6, and the reuse is documented as a study limitation | §5.1 |
| MS3 | Authorship of artifacts was not stated | Every empathy map states its author and its interviewer | §5.1 |
| MS4 | Diagram images were hard to read | Each empathy map was replaced with a legible full-size image, and its four quadrants are transcribed in text so the content does not depend on reading the image | §5.2–§5.6 |
| MS4 | PAS: table format is recommended for legibility | All ten PAS hypotheses are now presented as Field/Description tables instead of prose | §2.1–§2.5 |
| MS4 | Context Canvas: constraints could be more specific and contextual | Rewrote the three Constraints columns as research-grounded statements instead of restated design goals | §3.2 |
| MS4 | Context Canvas: the picture provided was not clear / low quality | Replaced the canvas image with a new version and paired it with the written constraints in §3.2 so the content doesn't depend on reading the image alone | §3.1 |
| MS4 | Business Questions: some Type 2 questions focus on internal analysis rather than direct user-facing insights | Reformulated the affected questions as direct student-facing answers to remain Type 2 (BQ-04, BQ-05), and reclassified the entrance-presentation question as a Type 3 controlled-pilot comparison instead | §6.2, §6.3 |
| MS4 | VD Map: the picture was very low quality, though the link to the original was provided | Replaced the VD Map with a new full-resolution version and linked the original file; the fourteen questions, their data sources and their processing are traceable in §7.2 and §7.3 | §7.1, §7.2, §7.3 |
| MS4 | No establishment owners were interviewed | The analytics persona is labelled as a design hypothesis and the missing owner research is stated explicitly as a pending task | §4.3 |