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 as the sole Senior Product Designer in January 2026 and owned the full design arc from discovery and problem framing through high-fidelity execution and working prototypes. The mandate was straightforward: 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 important for the waiter app and KDS where cognitive load during service is already high.
• Add-on modules like the Staff Portal and catering features must feel native, not bolted on. Same design system, same interaction patterns.

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.

Key Flows Designed

• Waiter floor management: seating guests, building orders by table, sending to kitchen, splitting and completing payment.
• Customer QR flow: scan the table code, browse the menu, add to cart, pay with Apple Pay or Google Pay.
• Kitchen display: real-time order receipt, item status updates, fulfillment marking that propagates back to the waiter app.
• Restaurant Panel: drag-and-drop floor plan editor, reservation and waitlist management, live order view, and reporting.
• Cashier and admin mode: same device as the waiter app with elevated privilege access for managers.

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.

Results were measured through POS logs and prototype testing sessions during pre-production. Waitery is currently in the investor and pre-deployment phase. These metrics reflect the redesigned flows compared against baseline measurements from the original system.

Designing for Multiple Simultaneous Actors

The hardest design challenge wasn't any single screen. It was making sure that an action in one app triggered exactly the right response in two others, without any of those transitions feeling like a handoff. A customer paying for their items needs to lock those items on the waiter's view and clear them from the kitchen's queue. Getting any one of those three states wrong breaks the entire interaction. That kind of systems thinking is invisible in any single screen, but it determines whether a product actually works in a restaurant.

AI as a Prototyping Accelerator

Claude Code Pro changed the shape of the design-to-engineering relationship. Static Figma handoffs invite interpretation gaps. Engineers fill in ambiguity with their best guess, and that guess often differs from design intent. Interactive prototypes that match the spec don't have that problem. The 20% reduction in iteration cycles came from less back-and-forth, not shortcuts. The design got better because the feedback loop got faster.

Design System Before Features

Starting with the component library before any feature screen was the right call. The 7-app scope would have been unmanageable without a shared foundation. Every new screen would have required re-solving layout, color, and interaction decisions that had already been made. Starting with tokens and components meant the hardest decisions were locked in and consistent before feature design even began.

Waitery is heading into the investor phase with a complete, working ecosystem. Seven apps, a unified design system, and working prototypes across all major flows. The pre-production metrics validate the design decisions made during discovery and execution.

As the sole designer, this project covers the full arc of product design: discovery, systems thinking, multi-persona UX, AI-integrated workflow, and hands-on delivery. It's the kind of B2B work I want to keep doing. Complex operating systems, multiple stakeholders, real operational stakes, and design decisions that trace directly to business outcomes.