Waitery

Waitery is a restaurant point-of-sale ecosystem built for operators who need more than a payment terminal. It's a connected operating system with 7 apps across mobile, tablet, and web. Every actor in the restaurant gets exactly the interface they need: the customer, the waiter, the kitchen staff, the manager, and Waitery's own support team.

I joined in January 2026 as the sole designer and took it from discovery all the way through to working prototypes. The brief was clear: take a fragmented 3-app system with no shared design language and turn it into a coherent product ready for production and investors.

• Waiter app: floor management, ordering, and checkout on a Clover Android tablet.
• KDS: kitchen display for order receipt and fulfillment.
• Cashier app: the waiter app on a larger screen with manager-level admin access.
• Restaurant Panel: web dashboard for managers covering orders, floor plans, reservations, reports, and settings.
• Staff Portal: web app for shift scheduling and swaps.
• Web Ordering app: customer-facing QR code flow for scan-to-pay.
• Admin Panel: Waitery's internal control center for restaurant management, billing, and support.

Before the redesign, Waitery had 3 separate apps. One for the customer, one for the waiter, and one for the kitchen. Each was built independently with its own visual language, its own interaction patterns, and no shared component library. A restaurant using all three was effectively using three different products.

What Was Breaking

• No shared design language. A waiter glancing at the customer's phone saw a completely different visual system, breaking trust at every handoff point between actors.
• No unified component library meant every new feature required re-solving problems already solved elsewhere in the product. Inconsistency compounded with every release.
• The kitchen and waiter apps had no real-time feedback loop. Kitchen staff had to verbally communicate order readiness to the floor, adding noise and delays in high-volume service.

Ordering Flow

Before touching any UI, I mapped all actor types and their jobs-to-be-done. That exercise produced the insight that shaped every decision that followed: this isn't 7 apps. It's one operating system with 7 entry points. Every actor has a different view into the same underlying data layer. The design constraint was simple to state and hard to execute: zero friction at every entry point, with a shared visual language underneath all of them.

The Key Insight

In a POS ecosystem, one actor's action immediately changes what two or three others see. A customer submitting an order should trigger a notification on the waiter's tablet and a new ticket on the kitchen display, with no perceptible delay and no ambiguity about which table or which items. Designing for this meant tracing the UX end-to-end across the full actor graph, not designing app by app.

Design Principles

• Actors should never need to context-switch visually when they interact with another actor's output. Shared visual language is non-negotiable.
• Every screen has exactly one primary action. No competing CTAs, no ambiguity about what to do next.
• The system surfaces what matters next, not everything at once. This is especially critical for the waiter app and KDS where cognitive load during service is already high.

Design System First

The first deliverable was a unified component library, not a single screen. Shared tokens for color, spacing, and typography were set before any feature work began, covering the POS tablet, web dashboard, and mobile web. This was the foundation that made 7 apps feel like one product. Every hour spent on tokens and components paid back across the full product surface. Without it, the 7-app scope would have been unmanageable.

Claude Code Pro as Prototyping Partner

The most significant workflow change was using Claude Code Pro to translate Figma designs directly into interactive prototypes. Instead of static handoff files that engineering has to interpret and re-implement, I generated working code that matched the design spec. This cut design iteration cycles by 20% before handoff. It was especially valuable for the web ordering flow and restaurant panel, where complex real-time state like table status, in-flight payments, and order routing is nearly impossible to communicate through static screens. The tool didn't replace design judgment. It removed the translation cost between design intent and engineering implementation.

The result is one operating system with 7 entry points. Each is tuned to the actor using it and all share the same design foundation. Every app was built around a single primary action per screen, real-time state propagation across actor boundaries, and a visual language consistent enough that switching between apps requires no reorientation.

Running on a Clover Android tablet. Waiters see the full floor plan on load, seat guests by tapping a table, build orders from a structured menu, and send directly to the kitchen. Real-time push notifications fire when an order is ready or when a customer calls for service. Checkout supports full-table payment, payment split by item, or payment split by person. One primary action per screen throughout.

• The hardest challenge wasn't any single screen. It was making sure an action in one app triggered exactly the right response in two others. A customer paying locks their items on the waiter's view and clears them from the kitchen queue. Getting any one of those three states wrong breaks the entire interaction. That kind of systems thinking is invisible in any individual screen.
• Claude Code Pro changed the design-to-engineering relationship. Static Figma handoffs invite interpretation gaps. Interactive prototypes that match the spec don't. The 20% reduction in iteration cycles came from less back-and-forth, not shortcuts.

Seven apps, a unified design system, and working prototypes ready for investors. The pre-production metrics validated the decisions made during discovery. As the sole designer, this project covers the full arc: systems thinking across multiple simultaneous actors, AI-integrated workflow, and design decisions with real operational and business stakes. It's the kind of work I want to keep doing.