Bar Tabs &
Table Service

Research the pressure, not only the screen.

I began with published research and a review of ten point-of-sale products. I studied common patterns for tab creation, navigation, merging, splitting, and transfer.

I interviewed 15 waitstaff and managers across different establishments. We returned for customer sessions and used expert whiteboards to test our assumptions.

The research produced nine recurring frustrations. They included unpaid tabs, slow navigation, difficult transfers, inflexible bill splitting, poor visibility in dark rooms, and long training.

Our design question became: how can we reduce errors and improve service speed during a busy shift?

One overview, with clear rules for every action.

Personas, user stories, and task flows turned the research into a working model. The centre of that model is the Bar Tabs Visualizer: every open bill in a tile or list view, with search, quick view, ownership filters, and visible status.

1. Create a named tab and move directly into ordering.
2. Recall a tab after checking ownership and permission.
3. Keep the staff identity and tab name beside the active order.
4. Close a tab using its payment state and permission rules.
5. Reopen, transfer, merge, import, or split through explicit actions.

Feedback changed key decisions. We replaced drag-and-drop splitting with select-and-assign, because the original model created a steeper learning curve.

The first release focused on single-server tabs. Shared transactions and transfer flows required a separate phase.

Move from sketches to real service conditions.

The work moved from whiteboards and paper sketches through low, medium, and high fidelity prototypes. Each round made the workflow more specific.

We defined test goals, recruited target users, ran usability sessions, and watched the system in realistic tasks. Product vision and engineering limits met through repeated review.

The close-tab handoff alone used 27 frames to show normal, paid, bill-printed, in-progress, and denied-access paths.

Release testing found forced logout during restricted access. The correction brought manager approval into the workflow, where staff could recover without losing their place.

Carry service state onto the restaurant floor.

Table Service extends the same model into a spatial view of tables, seats, and service status. I directed its AI-assisted design and coded prototype.

1. Backoffice holds the main floor-plan editor.
2. The point-of-sale view supports live service and quick table access.
3. Empty, loading, error, permission, offline, and conflict states define recovery.
4. Unsupported product capabilities stay visible as dependencies before build.

The pictured editor is an earlier exploration. Its placement changed during later design work.

Bar Tabs reached release. Table Service remains in design. The next measures should cover recall success, closing time, permission failures, and recovery completion.