Back to works
[ PROJECT 05
— RESERVATION ]
A tablet for hosts and floor managers to run reservations, walk-ins, waitlists, and seating in one place. Every table carries its own live state and every guest brings their history, so the host can make fast, informed seating calls mid-rush.
Project Type
Hospitality operations tool
Role
UI/UX Designer
Timeline
Platforms
Tablet (1024×768) · Web CMS
[ THE CONTEXT ]
The host stand is a glance-driven job
TABLE STATE CHANGES CONSTANTLY
Capacity, timing, and turn status shift every few minutes through service.
A LIST CAN'T SHOW THE ROOM
A reservation list answers who and when, not what's open, where, right now.
A MAP CAN'T SHOW THE QUEUE
A floor plan on its own hides who's next and who's running late.
GUEST CONTEXT ARRIVES TOO LATE
Tier, preferences, and no-show history matter at the door, not after seating.
[ DESIGN FOCUS ]
So the interface has to compress a whole service, status, timing, capacity, and guest context, into something a host can read in a glance and act on in a tap.
Three directions, all about making the room readable at a glance.
01
Pair the list and the map
Two linked views of the same service, so the host reads whichever answers the question in front of them.
02
Make every table state legible
Encode capacity, timing, and turn status on the table itself, so the floor reads without a single tap.
03
Bring the guest to the door
Surface tier, preferences, and history at the exact moment of the seating decision.
[ SOLUTION ]
The screen is split into two linked halves, a reservation queue and a live floor, so a host can answer both who's next and what's open without leaving the view.
SOLUTION 01
The floor plan as a live dashboard
Each table is a status object: capacity (2/4), a fill bar, a time chip that turns red when a booking runs late, and a shape that reflects the real table, round, square, or a long communal top. The host reads the whole room's health without opening anything.
KEY DECISION
The table, not a list row, is the primary status object. The floor plan is the dashboard, so the most decision-critical information lives exactly where the host is already looking.
SOLUTION 02
A queue that stays in step, and one flow to fill it
Beside the floor, reservations group by lifecycle, Upcoming, Seated, Completed, Cancelled, with live counts and one-tap status advancement; selecting one highlights its table on the map. A single create flow handles reservations, walk-ins, and waitlist, with the waitlist toggle appearing only for walk-ins.
KEY DECISION
A booking's seated duration drives the floor's turn-times and the red running-late state on a table, so the queue and the room stay in sync.
SOLUTION 03
The guest profile, at the point of seating
Choosing a guest opens their full profile inline: tier and VIP status, a 12-month summary of visits, completed, cancelled and no-shows, behaviour tags, preferences, and loyalty points. Enough to make a confident seating call, priority table, allergy note, repeat no-show, without leaving the booking.
[ WHAT IT ENABLES ]
The host stand becomes one screen that answers spatial and sequential questions at the same time. Room status and the reservation queue are readable without switching context, a guest's tier and no-show history are present before the table is assigned, and walk-ins and waitlist live in the same flow as booked reservations.
[ REFLECTION ]
01
LEARNED
The strongest move was making the floor plan itself the dashboard. Once every table carried its own state, the host stopped reading the screen and started glancing at it.
02
CHALLENGE
Density versus legibility on a single table tile. Capacity, timing, and turn status all have to fit an object the size of a thumbnail and still read across the room.
03
WHAT’S NEXT
Validate the core interactions, then extend: can a host find an open table for a given party size in one glance, is a late table obvious without tapping, and does the guest profile give enough to make the seating call at the door?
/ LET'S WORK TOGETHER
I'm open to collaboration and new opportunities
/ GET IN TOUCH