1. Value Proposition
2. UI/UX Design
   • 2.1 Color Palette
   • 2.2 Typography
   • 2.3 Icons and Images
   • 2.4 UI Prototype
   • 2.5 Navigational Patterns
3. Known Gaps Carried to MS7
4. References

For students. UniEat lets students settle on a food option that fits their budget, dietary requirements, location, and available time before they leave the classroom. Today that information only surfaces once they are already walking. For Alex (persona, MS3), it is enough trustworthy information to actually try an unfamiliar place instead of falling back on the one she already knows. For Diego (persona, MS3), it means choosing on purpose during his fixed one-hour break, rather than ending up wherever happened to be on the way.

For establishments. UniEat gives small, mostly unstaffed food businesses a channel to reach students who are actively deciding nearby, plus a way to see whether posting actually produced any interest. That second part matters. Owners who publish every day and get nothing back have little reason to keep doing it.

Differentiation from existing alternatives. Students currently rely on friends, Google Maps, generic review sites, and physical exploration. The differentiation is the combination of the rows below, not any single row on its own.

This value proposition remains a design hypothesis. Its impact has not been measured through a deployed application.

The palette follows a Neo-Flat / Bold Pop direction, using solid black borders instead of soft shadows and flat, high-contrast color blocks. Color carries state (fresh, live, confirmed, pending report) rather than decoration, so the feed stays readable in the few seconds a student has between classes (QS-3.2).

Swatch	Color	Hex	Usage	Rationale
	Yellow (primary / brand)	#FFDF00	Header, primary CTAs, active nav tab	High contrast under campus daylight, and reads as an action rather than decoration
	Black (structural border)	#111111	2.5–3 px solid border on every card and control	Replaces drop shadows with a hard contour, so cards stay legible without gradients that wash out outdoors
	Black (text)	#111111	Dish name, establishment name, body and meta text	17.8:1 on the cream background, well above the WCAG AA 4.5:1 floor
	Lime Green	#A3E635	"En Campus" tag, "Sigue igual" confirmation (BQ-07)	Reserved only for confirmed-fresh or verified state, never a default neutral, so it does not lose meaning
	Cyan	#00F0FF	"¿Indeciso?" banner, active filter selection, accuracy badge	Neutral, informational state that implies neither error nor confirmation
	Orange, current	#FF5400	Budget value in the feed header, sorteo winner price, "Marcar agotado" link	Intended for time-sensitive numeric data. Fails WCAG AA as text on cream, replacement specified below
	Deep Orange, specified replacement	#C43D00	Same role, from the next export onward	Same hue role, and passes AA in both directions. See Contrast verification
	White (badge fill)	#FFFFFF	Price badges in the feed and the detail card	Black numerals on a white fill inside a black border, 21:1. The highest-contrast treatment in the UI, applied to the single most-cited decision criterion
	Coral	#E5484D	Specified: "Reportar cambio" and error states. Currently: the "¡Ganador del sorteo!" badge	Specified to keep the report action visually distinct from the primary yellow CTA, per the fairness commitment in §10.1. The current assignment contradicts that role, as discussed below
	Cream	#FAF8F5	App background	Keeps focus on the food cards rather than on chrome

Every foreground and background pair in the UI was measured against WCAG 2.1 AA, which requires 4.5:1 for normal text and 3:1 for large text and non-text UI components.

Identified defect and specified correction. The orange assigned to time-sensitive values does not meet AA as normal text on the cream background (3.0:1), nor as a badge fill with black text (3.1:1). The specified correction is #C43D00, which reaches 5.0:1 as text on cream and 5.3:1 as a fill with white text, while keeping the same semantic role. Black text on the replacement was also measured and rejected at 3.6:1, which is why the corrected badge fixes its text color to white rather than leaving it flexible. The token is defined here and applied in the next prototype export. The screenshots in §2.4 still show the original orange.

Two scope notes, taken from an audit of the screens in §2.4 rather than from the style guide:

• Dish prices are not affected. They render as black numerals on a white fill inside a black border (21:1), which is the strongest contrast treatment in the UI. Price is one of the two most-cited decision criteria across all three interviews (I1-S3, I3-S1, I6-Q2), so applying the highest-contrast pair to it is the correct priority and is kept. The defect is therefore confined to the budget value in the feed header, the sorteo winner price, and the "Marcar agotado" link.
• Orange is specified for time-sensitive numeric data, but is not applied consistently. It currently appears on the budget value and on an inline action link, while the "válido hasta" expiry label, which is the clearest case of time-sensitive data in the feed, renders as neutral text. Tightening this to a single rule is carried into MS7 (§3).

Semantic inconsistency in the coral role. Coral is defined above as the report and error color, but the only place it currently appears is the "¡Ganador del sorteo!" badge, which is a positive outcome, while "Reportar cambio" renders as a neutral white button. A color cannot carry both "something is wrong here" and "this is your result" without losing the meaning that justified reserving it. The resolution specified for MS7 is to return coral to the report action and move the winner badge to lime #A3E635, which already carries the confirmed and verified role.

Typeface. Space Grotesk, loaded via Google Fonts and applied globally across the current V2 prototype. Its bold, geometric weight matches the Neo-Flat / Bold Pop direction, and the tall, high-contrast letterforms hold up against the thick black borders and flat color blocks used throughout.

Numeral style. Tabular figures for prices and timestamps, so values align vertically across stacked feed cards. Price being a primary decision criterion makes this a functional choice rather than a detail.

Type scale. Sizes are in sp (scale-independent pixels) rather than points, so they respond to the system font-size setting. Line height is absolute to keep stacked feed cards on a predictable rhythm.

Minimum size. 14sp for any text a student reads in order to decide, meaning dish name, establishment name, price, distance, and queue time. Badges and micro-tags are contextual labels rather than decision-critical text, and sit at the 12sp accessibility floor.

Dynamic type. The layout is built to reflow rather than truncate when the system font scale increases. Feed cards grow vertically and the price badge wraps below the name instead of clipping, and no text in the feed sits in a fixed-height container. This is a build commitment. The static prototype does not exercise different font-scale settings, so it has not been visually verified (see §3).

The specified icon language is a single family across filters, navigation, and status badges: Material Symbols Outlined, weight 400, optical size 24, grade 0. It was chosen because its stroke weight matches the 2.5–3 px card borders. Icons are always paired with a text label, and none carries meaning on its own, so the UI stays usable for a student who does not recognize a glyph.

The font is already loaded in the prototype's <head>, but the current screens still render emoji in these positions. Replacing them is a token-level swap with no layout consequence, and is the first item scheduled for the next export.

No photographic content appears in the current prototype. The location card communicates the entrance with text only. The image system is specified here because the storefront photo is what makes the "recognize an unfamiliar entrance" row of §1 work, and specifying its empty state matters as much as specifying the photo itself.

Dish photos stay optional on the publication form and appear only as a small thumbnail, because the priority on the establishment side is a form an owner can finish in under a minute, one-handed, mid-shift. A missing photo must never read as "this place is closed or untrustworthy", which is why every slot has a defined empty state rather than a collapsed layout. Since the posting form is not part of this iteration, this is a requirement carried into MS7 (see §3).

The prototype lives in Google Stitch, building on the team's MS2 low-fidelity prototype and moving it toward the Daily Menu Feed direction selected in MS3. During this iteration the visual direction shifted from an initial Flat/Editorial style (V1) to the current Neo-Flat / Bold Pop style documented in §2.1 through §2.3.

🔗 Live prototype (V2, Neo-Flat): https://stitch.withgoogle.com/projects/6680127138406851432 🔗 MS2 prototype (starting point): https://stitch.withgoogle.com/projects/12917237623612741830

Static exports of every screen are embedded below so the deliverable is readable without external access.

Figure 1. V2 Neo-Flat / Bold Pop, the complete high-fidelity flow. Solid black borders, sticker-style labels, and a yellow, mint and coral palette applied over the original component code.

Figure 2. Menú. Publication cards carrying establishment, campus tag, queue estimate, dish prices and the validity window, with the "¿Indeciso?" shortcut pinned above the feed.

Figure 3. Filtros de búsqueda. Budget ceiling, total available time, dietary type and payment method, resolved in one screen.

Figure 4. Ficha de menú. The three-metric strip (queue now, walking time, accuracy) sits above the dish list, and "Sigue igual" and "Reportar cambio" close the freshness loop.

Figure 5. Elige por mí. A single randomised result drawn from the active filters, for deciding with zero comparison cost.

Every screen traces back to a PAS hypothesis and a Business Question defined in MS4.

Two hypotheses have no screen in this iteration and are tracked in §3: PAS 4 (establishment performance view) and PAS 9 (offline cached feed).

Persistent bottom tab bar with four destinations, Menú, Sorteo, Filtros and Publicar, which stays within the platform convention of three to five top-level destinations. There is no separate Profile tab. A small avatar chip in the header covers that role, keeping the bar limited to the four things a student actually does under time pressure.

graph TD
    A[Onboarding] --> B[Menú, feed]
    B -->|tap card| C[Ficha de menú]
    C -->|back| B
    C --> C1[Reportar cambio]
    C --> C2[Sigue igual, confirm]
    B -.tab.-> D[Sorteo, Elige por Mí]
    D -->|result| C
    B -.tab.-> E[Filtros]
    E -->|Aplicar| B
    B -.tab.-> F[Publicar, establishment form]
    F -->|Publicar| B
    B --> G[Estado: sin menú hoy]
    B --> H[Estado: sin conexión, feed en caché]

Figure 6. Navigation graph. Dotted edges are bottom-tab switches and solid edges are push transitions with a back affordance. Nodes are drawn from the specification, and those not yet present in the prototype are listed in §3.

Three decisions are worth calling out:

• "Elige por Mí" holds a full nav slot, rather than being a button on a card. That is a deliberate promotion from secondary action to primary destination, and it maps directly to Diego's persona. For someone deciding under real time pressure, "just choose for me" earns a first-class path rather than an afterthought.
• Filtering is a destination, not a control on the feed. V1 had a free-text search bar ("¿Qué se te antoja almorzar hoy?"). V2 dropped it and promoted filtering to its own bottom-tab destination, keeping only quick dietary chips and the budget value inline on the feed. Typing a query is a poor fit for someone walking between buildings with one hand free. The trade-off is acknowledged. Moving the full filter set off the feed costs the "no settings menu to dig through" goal from the original constraint, and is accepted because the chips and the budget value keep the most-used constraints one tap away.
• Single-view forms for time-constrained tasks. The establishment posting form and the student onboarding are each specified as one scrollable view with no wizard steps, so an owner can post mid-shift without losing progress. Neither screen exists in the prototype yet (see §3).

Non-happy-path states are specified as first-class screens rather than afterthoughts, covering "no menu published today", "insufficient information" on the waiting-time card, and the offline cached-feed banner. Each must communicate missing data, never an absence of options, because a feed that looks empty when the network is down would break the trust the whole product depends on. These are not in the prototype yet (see §3).

Stated once here rather than scattered through the document.

[1] W3C, Web Content Accessibility Guidelines (WCAG) 2.1, Level AA success criteria 1.4.3 and 1.4.11.