Restaurant POS: rebuilt for iPads, dinner rushes, and right-to-left
Waitstaff were running a 1990s desktop POS through iPad mirroring. Eight modules rebuilt for touch and right-to-left reading over three years. Support calls down 80%.
iPad
B2B
Hospitality
RTL
Role
Sole Product Designer
Timeline
Jan 2023 – Mar 2026
Market
Restaurants, RTL-native
Platform
iPad
Team
1 designer · 1 PM · 3 developers
Methods
Research Plan · Contextual Interviews · Personas · Journey Mapping · Information Architecture · Design System · RTL design
The order screen — where a non-linear conversation becomes a kitchen ticket.
Overview
Three years, eight modules, a 90s point-of-sale rebuilt for iPads in an RTL market. With the waitstaff 3,000 km away, I built the evidence in Gdańsk restaurants and named what it could and could not prove.
Over three years I led the end-to-end redesign of a legacy point-of-sale system used by full-service restaurants in an RTL-language market, replacing a 90s, PC-native interface that waitstaff were running through iPad mirroring.
Eight modules shipped to production, incrementally, on a design system I built and maintained for the product. Support calls for the new product fell by 80%, by the client's own account.
Problem
Designed for desktops, dying on iPads — every tap was a workaround.
The client, a software company serving hundreds of restaurants, was losing customers to the dominant modern competitor. The root cause was structural: their POS was built in the 90s for PC and mouse, but waitstaff in 2023 were using it on iPads.
The stakes were blunt: the product needed to sell, and it was not attractive enough to sell. Restaurant staff, mostly 16 to 25 years old by the client's account, working dinner rushes where every mis-tap reaches the kitchen printer, deserved better than a mirrored desktop app.
The constraints I designed inside of:
No direct access to end users. The waitstaff were 3,000 km away, and getting to them in person was never on the table. Everything I learned about their shifts reached me second-hand, through the client's product owners.
RTL-native UI. Navigation, layout and information architecture were designed right-to-left, not mirrored from an LTR original. A flipped interface inherits reading order, alignment and icon direction from a language it was not built for. Designing RTL-native is an inclusive-design decision, not a localisation step.
Incremental releases to live restaurants. No staging environment full of test users. Every shipped feature landed in real dinner services immediately.
The same screen, twenty-five years apart.
Research
Since I couldn't observe the actual waitstaff, I designed a proxy study — and named exactly what it could and couldn't validate.
Since I could not observe the actual waitstaff, I built the evidence myself.
Contextual interviews and observation in three Gdańsk restaurants (November 2023), built on a full research scenario: goals, research questions, task walk-throughs. From this came the main persona and a shift-manager journey map that anchored design decisions for the next two years.
The trade-off, named: Polish restaurants could validate the mechanics of the job, how orders flow, how waiters communicate with the kitchen, where errors happen. They could not validate market specifics: the local payment ecosystem with its third-party meal-voucher schemes, how bills get split there, or RTL reading patterns. Those I sourced separately, through structured domain sessions with the client's product owner.
The single most valuable finding came from a waitress in a Gdańsk taqueria: guests never order in the sequence the system expects. Her workaround was typing “TO START” in caps into the kitchen notes and hoping the kitchen noticed. Reordering items on the ticket, she said, would change her daily work. That insight, that order-taking is non-linear and the ticket must bend to the conversation, shaped the entire order screen.
I also tried to build a research channel that did not depend on me travelling: survey scripts for the client's own restaurant visits, and an in-prototype desirability survey triggered after a key flow. Neither happened; the surveys were never run, the questionnaire never filled in. What did work: incremental production releases, structured feedback sessions from two restaurants relayed back to me, and one outside design review the client arranged. That reviewer's verdict was blunt, better than the old app but not good-looking enough, and it was the kind of unfiltered read I had no way to get on my own.
The Gdańsk proxy study: scenario, persona, shift-manager journey map.
Key decisions
Four decisions.
Decision 01 · Adoption
Familiarity over a clean slate
I kept the old system’s spatial logic for the floor map and order window and spent my innovation budget elsewhere. Nobody asked me to — no one on the client side raised it as a requirement, and I made the call before the first wireframe. The payoff I was after: experienced waiters could move to the new app without retraining.
Why
By the client's account, thousands of waiters had years of muscle memory in the old layout. Jakob's Law: people spend most of their time in other interfaces, and here that meant the previous version of this one. On a restaurant floor, relearning where a button lives does not cost annoyance, it costs seconds per order in the middle of a dinner rush.
Trade-off
I sacrificed the chance to fix legacy information architecture I disliked. Familiarity won over correctness — deliberately.
Decision 02 · Order flow
An order ticket that bends to the conversation
Guests order non-linearly; the old system punished that. The new order screen lets waiters add, edit and reorganize items in any sequence before firing to the kitchen — directly answering the ”TO START” workaround from research.
Why
Order-taking is a conversation, not a form. The ticket has to follow the guest, not the database schema.
Decision 03 · Iteration
Variant selection, iterated on production feedback
Feedback from two restaurants in the client’s market flagged variant selection as the top usability pain: too much scrolling, and no visible signal when a selection limit was reached. I redesigned the flow with automatic scroll to the active variant group and explicit limit states — Nielsen’s visibility of system status, applied where it hurt most. The same loop set the priority order for the next quarters: payments first, dialogs second, variants third.
Why
This was the loudest, most specific signal the mediated feedback channel ever produced — worth spending a redesign on.
Decision 04 · Auth
One login model doesn't fit
Some restaurants run one shared iPad; others give every waiter their own. A single auth pattern couldn’t serve both — per-action PIN entry is tolerable on a shared device and infuriating on a personal one. I designed both modes, configurable per restaurant.
Why
Fit with how restaurants actually operate beats elegance of a single flow.
Trade-off
I sacrificed the simplicity of one flow — two auth modes mean two paths to design, test, and support, forever.
Outcome
A product that was losing clients became the one the company leads with.
80%
fewer support calls for the new product
3 yrs
in production, shipped incrementally
8
modules live — from order taking to X/Z reports
RTL
designed native, not flipped
”Customer calls to technical support for the newly developed product have decreased by 80%.”
— the client's CTO, verified Clutch review, January 2026
Shipped to production over three years: order taking, payments including local third-party methods, floor map, delivery order management, X/Z reports, staff clock-in/out, user and role management, settings. Eight modules on a design system I built and maintained for the product, RTL-native throughout. The client's own verdict: a product that used to be hard to sell now sells easily. My engagement ran from January 2023 to March 2026.
Four months after it ended, the client sent me a video from an industry trade fair: rows of iPads on their stand, all running the redesigned system, shown to prospective customers. The product that had been losing them clients had become the one they lead with.
Reflection
I spent too long trying to make mediated research work.
Surveys handed to the product owner, questionnaires embedded in prototypes — none of it produced a single data point. Knowing what I know now, I would negotiate direct access as a condition early, when leverage was highest: even two recorded remote sessions per quarter would have replaced a year of second-hand relay. And I would push for product analytics in the first release, so the feedback loop wouldn’t depend on anyone’s goodwill.