Your host stand is your product. Design it like one.

Not at 3pm in an office. Real test: two hosts, three walk-ins queued, a waitlist SMS reply, a phone call, and a delivery driver at the same door. If the tool takes more than two taps to seat a guest in that scenario, it will fail. Ours did — twice — before we built our own.

This is the same principle Steve Krug wrote up 20 years ago in Don't Make Me Think — you don't test software in the environment where it works. You test it in the environment where it fails. For a host stand, that environment is peak service on the second sitting on a Saturday. Everything else is theatre.

Every reservations tool we replaced at Reserved failed at least one of these tests. OpenTable's floorplan was fine at 3pm and lagged at 7:45pm. ResDiary's search-a-guest flow was 4 taps deep. SevenRooms was fast but required a laptop-shaped device on a stand that got in the way of the greet. None of these are bad products. They just weren't designed for the moment they were used most.

A new host should be able to seat, note, and re-assign on their first shift. That's the design bar. If your tool needs a two-day onboarding to use the floorplan, the tool is wrong, not the host.

Test it: hire a hostess, hand them the tool, watch them for the first hour of service with no prompting. Every tap they hesitate on is a design bug. Every screen where they ask 'where's the...' is a hierarchy problem. Every guest they nearly misseat is a state-visibility problem. This is not a hospitality problem. It is a UX problem.

The comparison that lands with every operator is the airline check-in kiosk. British Airways redesigned theirs after realising 40% of check-ins escalated to a staffed agent. The redesign — bigger tap targets, plain-English states, one primary action per screen — dropped that number to under 5%. Same passengers. Same flights. Different interface. Your host stand is a check-in kiosk that greets a guest and produces a memory. Design accordingly.