overview_
Ask a server what they think about the POS system they use and you will not get a measured answer. You will get a specific, vivid complaint about one screen, at one moment, on one shift — the tab they could not find at 11pm with six people waiting, the check they could not split without calling a manager, the screen so bright they stopped being able to read it two hours into a bar shift.
We heard eighteen distinct versions of that complaint. They came down to three things: servers could not see what they needed, could not reach it fast enough, and could not fix it when it went wrong.
Volanté’s existing POS did what every POS on the market does. It managed tables, took orders, opened and closed tabs. We audited nine competing systems, including our own, and every one of them handled those basics competently. What none of them handled was the part servers actually struggled with — customizing the interface to how a specific person works, merging and transferring tabs without friction, and navigating the thing at speed under pressure.
That gap was the product.
How might we streamline the bar tab interface to reduce errors and improve speed of service for servers during busy shifts?
The cost of getting it wrong was not abstract. A server who cannot find a tab is a table waiting. A check that cannot be split is a manager pulled off the floor. A void that takes six taps is revenue leaking, and it is the kind of leak that never shows up in a report because nobody logs the ninety seconds they lost.
There was a second problem underneath the first, and it turned out to matter more. Every server using our POS had already built muscle memory around it — bad muscle memory, on a bad interface, but real. Any redesign good enough to fix the interface was, by definition, unfamiliar enough to slow them down on day one. Fixing the system and not disrupting its users were directly opposed goals.
That tension is what the project was actually about.
role_
I worked on the research phase alongside with my lead designer, and I was the more active hand in the design execution and in taking the work into the room with developers, product owners and internal stakeholders.
That second part is the part worth paying attention to. A research finding does not survive contact with a development backlog on its own. Someone has to sit in the review, explain why the dark screen path is not a nice-to-have, argue for the two-server authentication step when it is easier to ship without it, and hold the line when a design decision gets treated as a preference. That was my job on this project, and it is why the decisions on this page are in the product rather than in a deck.
WHAT I WORKED ON
· Bar Tabs Visualizer
· Keyboard and keypad system
· Ordering screen
· Dark mode path
· A portion of the tab actions
· Internal presentation to dev, product and stakeholders
WHAT THE TEAM OWNED
· Research programme across four streams
· Competitive audit of nine POS systems
· Prioritisation and backlog structure
research_
The research ran on four streams rather than one, which is unusual for a feature-level project and is the reason the conclusions held up.
INTERVIEWS
Fifteen servers and managers across different establishment types, working from a guide covering workflow, error handling, interface usability, speed of service, training curve and reliability. We mapped the results into eighteen recurring pain themes.
SECONDARY RESEARCH
Material Design guidelines, Nielsen Norman Group, and competitor documentation. Three findings carried through the whole project: readability matters more than it sounds when someone is looking at a screen for eight hours, action findability directly determines ordering speed, and servers need the screen to bend to how they personally work.
COMPETITIVE AUDIT
Nine POS systems, five with full teardowns — including an honest one of our own product, which named the dated interface, the confusing action patterns and the reliance on manual workarounds. Auditing your employer’s product in front of your employer is uncomfortable and it was the most useful slide in the deck.
INTERNAL EXPERTISE
Several people on the team had worked as servers and held current service certification. We used them as a standing check on whether a design would survive an actual shift.
15
servers and managers interviewed
18
recurring pain themes mapped
9
POS systems audited, 5 with full teardowns
BIAS AUDIT
We ran a bias audit before analysis — naming status quo bias, confirmation bias, expert bias and familiarity bias, and checking our conclusions against each. Expert bias was the live risk: we had ex-servers in the room and it would have been easy to let the loudest experienced voice stand in for fifteen interviews.
decision_
LEGACY FAMILIARITY VS. CLEAN-SHEET REDESIGN
The obvious move was a clean-sheet redesign. The existing interface was dated, the action patterns were confusing, and we had a documented list of everything wrong with it. Rebuilding from zero was the option most likely to produce something we were proud of.
We did not do that, and the reason came from the research rather than from taste.
Three findings pointed the same direction. Servers named the learning curve as a top frustration. Managers told us training time was a real operational cost, not an inconvenience. And our internal experts were blunt that a server mid-shift does not learn — they reach for where the button was last week and get annoyed when it moved.
So we split the surface in two. Where a prior mental model existed — layout, iconography, naming conventions, the ordering flow — we kept it, even where we could have improved it, because the cost of relearning outweighed the gain. Where no prior model existed, most of all the Visualizer, we were free to design properly, because there was nothing to unlearn.
OPTION A — FULL REDESIGN · REJECTED
Better interface on paper, worse first week for every server using it. In a category where a bad first week gets the rollout cancelled, that is not a trade we could make.
OPTION B — RESTYLE ONLY · REJECTED
Leaves the findability and speed problems untouched. This is what most of our competitors had already done, and it is why the market gap existed in the first place.
OPTION C — SPLIT THE SURFACE · CHOSEN
wireframes_
iteration_
THE ROUND THAT DID NOT WORK
Our first mid-fidelity prototype was rejected.
We put up the Visualizer, login-scoped tab visibility, the user profile with colour and initials, and a grid/list toggle. Feedback came back with nine required changes: preserve familiarity, rework split view, smooth out tab transfer and merging, simplify scheduling, prompt for headcount, reconfigure the panel layout, add real search and filtering, add clearer visual cues, and resolve ownership of future tabs.
Read together, the notes said one thing. We had designed the new capability well and had not yet reconciled it with the system people already knew. The familiarity constraint was in our research from the start; we had not yet let it constrain us.
So we went back through ideation a second time and came out with a prioritised backlog across five areas — unifying the POS and bar tab surfaces, the Visualizer, the left panel, the tab actions, and the floorplan. The second round is the one that shipped.
ROUND 01
ideate → sketch → mid-fi prototype
✕ REJECTED
9 CHANGES REQUESTED
ROUND 02
ideate → sketch → prioritise → mid-fi
✓ SHIPPED
interface_
Five decisions, each traceable to a documented finding. These are the ones I carried through development.
01 · DARK SCREEN PATH
Came directly from servers describing eye strain and unreadable screens in low-light bar environments. It reads as a styling choice. It was a findings-driven one.
02 · TWO-SERVER AUTHENTICATION ON MERGE
Came from user stories about accountability — merging two servers’ tabs moves money and responsibility, and doing it silently creates disputes nobody can resolve afterward. It adds a step. It was worth the step, and that is the argument I had to make in development.
03 · PER-SERVER PROFILES
Colour, initials, and screen orientation including a left-handed layout. Answered the customization gap no competitor had filled. The left-handed option came out of watching how people actually use the device.
04 · THE VISUALIZER
Search, sort, filter and a status legend, on a surface with no prior mental model to preserve. Answered “difficult tab search” and “no real-time updates,” two of the most frequently raised pain themes.
05 · KEYBOARD AND KEYPAD SYSTEM
Customer name entry with a card-swipe alternative, pincode entry with manager override, weight-scale entry. Most of the delay servers described was not the task, it was the input.
outcome_
A portion of the tab actions shipped alongside those four surfaces. The remaining actions and the table service floorplans are designed and awaiting development.
I do not have post-launch metrics for this work, and I would rather say so than estimate. The usability testing phase was scoped in the project plan and was not run before handoff.
What I do have is this: after the bar tab work went out, a customer using our POS asked us to build table service and floorplans on top of it. That request is why the product expanded past its original scope, and it is the most direct evidence I can offer that the shipped work did its job.
4 surfaces shipped
visualizer · keyboard and keypad · ordering screen · dark mode path
Scope expanded by customer request
a client using the POS asked for table service and floorplans to be built on top of the bar tab work
2 full design cycles
the first prototype round was rejected and rebuilt
reflection_
I would have run the usability test. We scoped a test phase and treated stakeholder review as a substitute for it. Stakeholders tell you whether a design is acceptable to the business. They cannot tell you whether a server can find a tab in four seconds at 11pm, and that was the actual question.
I would have applied the familiarity constraint before the first prototype, not after it. The finding was in our research from the Discover stage. We designed a round without it, had it handed back, and spent a full cycle learning something we had already been told. Research that does not constrain the first prototype is research you are going to repeat.
NEXT PROJECT