Attention
Seconds, not sessions
Categories and signatures have to land before the traveler looks back at the board.
Mondo Connex
Designing one ordering language for airport restaurants — so travelers can browse, customize, and pay under boarding pressure, whether they stand at a kiosk, order from a seat, or open the web menu.
3 surfaces
Kiosk, mobile, and desktop sharing one browse → customize → pay model
Guest + ops
Ordering UX tied to the tools that keep menus, service, and offers honest
Living system
Enterprise design system maintained and extended with feature releases
Under NDA. Only client-approved materials appear here. The work below is a partial view — enough to show the problem, the model, the living design system, and the craft bar.
Problem
Airports punish hesitation
Airport dining is a hostile UX environment: glare, noise, bags in both hands, multilingual travelers, and boarding-time anxiety. A flow that feels elegant in a quiet café can fail when someone has eight minutes before a gate change.
The product risk was fragmentation. Three surfaces designed as three products would force travelers to relearn ordering mid-trip — and force restaurants to maintain three truths about the same menu. The design problem was not “make a nice kiosk.” It was one mental model that still works when attention is scarce.
Interruptions
State must survive
Glare, gloves, companion questions, and app switching are normal — not edge cases.
Trust
Price before commit
Upsells and modifiers only work if impact is visible and reversible under pressure.
Model
Recognize before explore
The ordering spine stays constant across surfaces: browse → item → customize → cart → pay. Photography and labels carry recognition; customization is progressive; the cart is a confirmation cockpit, not a surprise total.
What stays unified is the job sequence and catalog meaning. What is allowed to diverge is density, gesture, and emphasis — kiosk leans on visual browse; mobile leans on compact detail and sheets; desktop uses higher bandwidth and modals without inventing a new language.
Unified
Jobs and meaning
Same catalog model, same customization rules, same commit logic — so a traveler who starts on one surface can finish on another without relearning the product.
Adaptive
Presentation only
Layout, chrome, and interaction density flex by device. The decision model does not — that is what keeps omni from becoming three disconnected apps.
- Browse Recognize categories and signatures in seconds
- Customize Safe defaults, reversible changes, visible price impact
- Pay Cart as confirmation before boarding anxiety spikes
Design system
A living product system — not a brand book
Mondo Connex needed an enterprise design system that could hold guest ordering and operator tools in one family: tokens, components, and interaction rules that ship with features instead of drifting per screen. This is product infrastructure I maintain and update with releases — foundations first, then components, then patterns — so new work inherits the model instead of reinventing chrome.
It is not a brand guideline. Brand expression can flex by restaurant; the system protects usability floors, state clarity, and a shared vocabulary across kiosk, mobile, desktop, and admin.
Foundations · Color
Guest action, operator chrome, shared neutrals
Guest action
-
White 5.7 AA
Primary / CTA
#307074Add to cart, steppers, key actions -
White 4.6 AA
Hover / emphasis
#3F8589Interactive lift without a new hue -
Black 8.2 AAA
Disabled / quiet
#9EB5B7Unavailable actions stay in-family
Operator
-
UI chrome
Admin primary
#1AAEAASidebar, toggles, help, focus -
Dark text
Highlight
#14C4BCActive nav / selected affordances
Neutral + text
-
Black 17 AAA
Surface
#FFFFFFCards, sheets, menus -
Black 15 AAA
Canvas
#F0F1F2Admin page background -
White 4.6 AA
Secondary text
#6E7678Descriptions, helper copy -
White 17 AAA
Primary text
#1A1A1ATitles, prices, labels
Foundations · Type
Hierarchy for glanceability and dense ops
Item title
Sans Bold · uppercase · guest headers
$24.00
Sans Bold · price / total emphasis
Body description for modifiers and pairings.
Sans Regular · readable under glare
Section label
Sans Medium · uppercase UI labels
Helper text for operator forms and constraints.
Sans Regular · admin helper / meta
Sans Medium · uppercase buttons
Foundations · Space
Rhythm that scales from kiosk tiles to admin forms
Base unit
8px Spacing, padding, and tap gapsGuest radius
8–12px Buttons, sheets, cardsTouch floor
≥44px Kiosk/mobile primary targetsElevation
Sheet / modal Scrim + raised surface for focusComponents
Reusable controls for guest and operator work
Buttons
Primary commits; secondary exits; ghost offers optional paths; admin chrome stays distinct.
Quantity stepper
Defaults safe; plus carries the action color; minus stays quieter until needed.
Selection
Checkboxes for guest modifiers; toggles for operator settings with immediate state.
Forms
Admin density with clear labels and helper text — same family, higher information load.
Patterns
Shared rules across surfaces
Navigation
Persistent decision chrome
Kiosk footer keeps accessibility, language, and order actions visible. Admin sidebar keeps venue settings findable without burying critical paths.
Feedback
State before surprise
Selected, disabled, and loading states stay in-token. Price impact appears before commit on guest flows; admin toggles reflect state immediately.
Content
Recognition over decoration
Photography and labels do recognition work. System chrome stays quiet enough for food and offers to lead — especially under airport glare and time pressure.
Governance
Maintained with feature releases
When a release introduces a new job — meal upsells, service QR modes, campaign builders — the system updates in order: token needs, component extensions, then pattern guidance. That keeps guest and operator surfaces coherent as the product grows, instead of accumulating one-off UI.
- Tokens Color, type, space — only if the feature needs a new meaning
- Components Extend buttons, forms, steppers, nav before inventing new controls
- Patterns Document the flow so future releases inherit the model
Surfaces
One model, proven three ways
The approved work shows the same decision path on mobile and desktop — item clarity, optional upsells, and a commit step that stays calm. Kiosk is the standing equivalent of that path: large targets, high contrast, and chrome that assumes interruptions.
Mobile
Progressive customization on a small canvas
Item detail leads; meal upgrades and pairings stay optional and priced. The structure holds when the UI is localized — proof that presentation changed, not the model.
Desktop
Higher bandwidth, same commit logic
Desktop keeps the catalog in view while the item modal carries modifiers and add-ons — more information at once, without a second mental model.
Accessible design
Reach, read, and switch without leaving the order
Assistive controls and language choice belong in the ordering chrome — not a settings detour. Guests stay on the same browse → customize → pay path when they adjust.
Reachable chrome
Controls where the hand already is
Accessibility sits with order actions in the persistent footer, so changing contrast or mode never means abandoning the menu mid-decision.
Language switch
Rewrite the path, keep the model
Choosing another language updates picker, footer actions, and the menu grid together. The browse → customize → pay spine stays familiar; only the presentation language changes.
Operations
Admin tools built for how franchises actually run
Guest UX only stays honest if managers can publish the truth for this location — its hours, its floor, its regional offer — without fighting a one-size franchise template.
Problem · Hours
Same franchise, different clocks
Sibling venues share a brand, not a schedule. MEL T1 may open breakfast at 05:30 while SYD T2 starts later. Category availability had to bind to the selected venue’s hours — not a franchise-wide default that would lie on the kiosk.
Why this shape. Hours live on the venue record and categories inherit or override them in place. That matched the POS/catalog model (per-location dayparts) and kept managers editing one location at a time instead of maintaining parallel menus.
Floor ops
Service that matches the room
Table and zone QR setup stays beside a live floor snapshot so managers can see what guests will scan before they publish — same venue scope as hours and campaigns.
Problem · Campaigns
Offers are local — language included
A campaign usually targets one region: creative, rules, and guest language all change. Regional managers still need to configure in English, then confirm the guest-facing copy in the local language before publish.
Why this shape. Language packs attach to the venue; the campaign card picks a pack (top right), and the final step translates English source fields into that pack. Manager chrome stays English — no second admin locale — while guest preview shows the generated local copy. Packs can be added as markets expand without redesigning the builder.
Close
What this work is meant to show
Even with limited public assets, the through-line is design judgment under constraint: protect one ordering model, encode it in a living enterprise system, let surfaces adapt without drifting, and treat accessible design and operator tools as part of the product — not afterthoughts.
When boarding starts in twelve minutes, the interface should already know what matters.
Continue
