A Platform Staff Worked Around — Not With
A restaurant management platform had every feature a hospitality team could need: reservations, floor plans, table status, zones, waitlists, service flows. But during the 45 seconds between seating a party and picking up a phone, nobody had time to figure out which icon did what. Support calls were the workaround.
Over a year, I led the redesign of the core workflows — from the reservation list to the floor plan to the information architecture of every card. The goal wasn't to add features. It was to make the existing ones usable under pressure.
The tool had everything. Nobody knew how to use it — and support was paying the price.
The platform covered every workflow a hospitality team needed. In practice, staff called support instead of using it. The support team documented the feedback. The patterns were consistent across all 4 user types.
9+ users. A support team's worth of documented pain. One clear direction.
The support team had been collecting user feedback systematically — the closest thing to a continuous usability study. Combined with direct observation sessions, it gave us a precise map of where the tool was failing.
Four roles. All working under pressure. Each failing in a different place.
Manage walk-ins and reservations simultaneously. Need to assign tables in real time — often without looking away from the entrance.
Failure: can't find the right reservation fast enough → guest waits.
Oversee occupancy and service flow. Need floor visibility without interrupting service.
Failure: can't read the floor at a glance → manual counting → decisions delayed.
Need table status and assignment updates during service. No time to navigate deep menus.
Failure: wrong table assignment → service errors.
Configure zones, rules, turn times, floor layouts. Less time pressure — but system reliability is critical. Failure mode: misconfigured settings create cascading errors during service hours.
If staff could read the interface as fast as they read the room, support calls would drop.
The opportunity wasn't to redesign the software architecture — the underlying logic was sound. The opportunity was to redesign the surface: the visual language, the information hierarchy, and the interaction patterns that staff encountered under pressure.
Make reservation status scannable by color — not by reading a label or decoding an icon.
Reservation list and floor plan should work together — not as separate contexts that require switching.
A consistent visual language that scales to the platform's complexity without adding to cognitive load.
This was a mature product with real users. A full redesign would require retraining. Every change had to feel like an improvement — not a replacement. Adoptable without a training session.
Map the system first. Then design for the moment — not the feature.
Not a new product. A usable version of the one that already existed.
The reservation card was the atomic unit of the entire platform. We mapped every field (state, time, party size, table, zone, name, date, prescriptor, comments, waiters, tags) and rebuilt the hierarchy from scratch — primary information at the top, status communicated by color at the left edge.
Design decision
Every field that required calling support to interpret was redesigned or renamed. The card was anchored around what staff needed in the first 2 seconds — name, time, table, status — not around database structure.
The original list buried customer names in small text among columns of equal visual weight. We introduced color-coded left borders for status, increased typographic hierarchy on names, standardized bottom navigation with count-per-status tabs, and added contextual tags as colored chips.
Design decision
Color-coded borders replaced icon guessing. A 1-second status read replaced a 10-second scan. The bottom tab bar — showing counts per status — gave managers an at-a-glance view of service state without opening a separate report.
The original floor plan required reading text on individual table blocks to determine status. We rebuilt it using color as the primary communication layer — each table block's background indicates its status. Text (time, name, pax) is secondary. Multi-floor navigation via tabs. Table blocks support 1/2/3 stacked reservations with hover to expand.
Design decision
The floor plan should be readable from 3 meters away. Color is faster than text. Before this change, finding a reservation required searching every table — after, status was a color, and the reservation list handled search.
The main view tried to surface everything simultaneously — counters, icons, toggles, and controls competing for attention. We restructured the navigation, introduced a dark-themed data table with avatar-based customer identification, clear filter chips, and a high-contrast primary action button. Secondary actions were grouped and deprioritized.
Design decision
Removing features from view isn't the same as removing features. Staff needed 3 primary actions for 90% of their service interactions. The redesign put those 3 in reach — everything else accessible but not competing for attention.
Every inconsistency in the original UI added to cognitive load. We defined an 8px base grid, standardized border radius (4px and 8px), selected Rubik as the primary typeface (Regular and Medium), and established a communication tone: warm, approachable, non-technical.
Design decision
Rubik and rounded corners weren't aesthetic choices — they communicate "non-technical" intentionally. The previous interface read like a developer tool. A hospitality platform serves people focused on guests, not systems. The design system made that distinction in every element.
Staff described a core frustration: finding a reservation required the list, placing it required the floor plan, confirming it required switching back. Three contexts for one task. We redesigned the main view to show both simultaneously — list on the left for search, floor plan on the right for spatial context. Actions in the list update the floor plan in real time.
Design decision
The two views weren't separate tools — they were two perspectives on the same data. Showing them together wasn't a layout decision, it was a workflow decision. It reduced the most common source of context-switching to zero additional clicks.
A clearer tool. A measurable goal. An incomplete project.
The goal was to reduce support call volume driven by interface confusion. The support team's documentation made it possible to measure this — every redesigned interaction had a corresponding support category. The design was delivered. Implementation was in progress when I left.
Three things that changed how I think about operational tools.
Great restaurant experiences start behind the scenes — with tools that let staff focus on people, not processes.
Designing for operational environments taught me that clarity and speed aren't design goals. They're business requirements. And a support team's documentation is the most honest usability test you can have.