A screen the customer sees, with no room to get it wrong
A customer-facing POS display where accuracy, speed, and trust all had to land at once.
The end user is a restaurant customer at the counter while their order gets built. They want it fast, they feel the line behind them, and they want discretion over how they tip.
For the business: a faster, more accurate checkout that builds trust, a loyalty program that makes regulars, and compliance with local customer-facing-display laws.
The Counter App on the actual POS terminal — the physical constraints before the UI shows up
So the first thing I did was go watch people use kiosks
My first kiosk project, so I started by observing how people actually use these devices.
The physical constraints broke my usual approach. What I found:
- Arm's-length interaction, so tap targets need to be larger
- Fast-paced, and people feel anxious holding up the line
- Lighting swings from bright restaurant to dim bar
- Fixed device, no adjusting angle or distance
- High cognitive load, so accessibility is critical
The environment matters as much as the interface. I used visuals only when they helped complete a task, and kept every interaction to the fewest steps.
Field research — arm's-length distance, lighting extremes, fixed device angle, annotated with what each constraint meant
Phase 1 — real-time order visibility, no interaction
Items appearing on the customer display one by one as the server rings them up — customers verifying their order live
We shipped the passive display first, and it taught us something
A non-interactive MVP validated the value and revealed how customers really used the screen.
Phase 1 was a passive order display: itemized list, subtotal, tax and total, branding, guest number, space for upsells. No interaction, just real-time visibility as the server builds the order.
It taught us something we didn't expect: customers watched the screen to verify their order and caught errors before checkout. That shaped how we prioritized accuracy and readability in Phase 2.
Dark mode was an accessibility call, not a style choice
Variable restaurant lighting made dark mode an accessibility decision, and it became the model for Aero-wide dark mode.
A bright restaurant and a dim bar are different contrast problems. Light mode in a dark bar creates glare and makes text harder to read at arm's length, the opposite of what someone needs to verify an order fast.
The Counter App was the first place we solved dark mode for real product use. The token structure we built here to handle light and dark independently became the model for the rest of the system.
Dark mode as an accessibility call — not cosmetic
The same screen flipping light to dark — glare problem in the bright restaurant, fix visible in the dim bar
Loyalty needed three doors because no single one fit every counter
Phone, email, and QR sign-up, because no single method worked across every environment.
QR works in some settings but fails in low light or a hurry. Phone is fast but the keypad eats screen space. Email works for some customers, not others.
So we gave people a choice. The flow let customers access their account, redeem deals, earn stars, and apply rewards at checkout.
Phone, email, QR — each entry point annotated with its tradeoff (QR fails in low light, keypad eats space, email is hit or miss)
What shipped: four phases, one uninterrupted flow
Four phases that add up to a single, uninterrupted checkout.
Passive display (Phase 1), on-screen payment with tip, signature, and receipt (Phase 2), loyalty with three entry points (Phase 3), dark mode beta (Phase 4).
A customer walks up, watches the order build, verifies it, inserts their card, tips, signs, picks a receipt, and optionally applies loyalty. One flow on a fixed Android device.
Four phases, one uninterrupted checkout flow
Three paths because no single method worked for every environment
Order builds, customer verifies, inserts card, selects tip, signs, picks receipt, applies loyalty — one uninterrupted flow
What I'd do differently: challenge the MVP scope sooner
Shipping Phase 1 passive made sense for risk, but the interactive value was clear from day one. We could have moved to Phase 2 faster with a tighter MVP definition.