Mews POS · Staff Product Designer · 2026
Six steps before the first product
Taking an order is why a restaurant installs the app. After four years on Mews POS, the Staff job was not another flow. It was to own that Golden Task: set the goal, name the causes, pick the bet, and ship it under a legacy constraint.
Year 2026
Platform Android
Role Staff Product Designer
Owned Problem framing, the bet, the first slice, how we measure
Constraint Java/XML · expert users · live service
Out of scope Rewrite · Compose · a visual refresh
The job at this level
Mews POS is the point of sale for hotel restaurants, bars and outlets. It runs in more than 1,000 properties, next to the PMS. In 2026 it was named Best Hotel Restaurant POS System at the HotelTechAwards.
I have been on this product for four years: workflows, foundations, keeping a complex surface coherent as several teams ship into it. This case is not “a screen I designed.” It is the moment I stopped letting take-order live as scattered UX debt and treated it as the reason the app exists.
What I set as success
I did not write a backlog of nits. I set four goals the work had to serve. If a proposal did not move one of these, it was not this initiative.
01 Speed on the happy path — Time to Take Order is the metric. A waiter adding a drink should not pass through admin first.
02 Unblock expansion — A multi-property group paused rolling Mews POS to the rest of their hotels until taps and time-per-task came down. This was a commercial problem wearing a UX costume.
03 Make the task measurable — Counter service had no clear start. You cannot improve a Golden Task you cannot instrument end to end.
04 Stop patching — Search, the stepper, a header here, a dialog there. Local tickets were hiding a system problem. The goal was one initiative, not twelve fixes.
The bet — and what I refused
The bet: configuration after action, not before. Sensible defaults do the work the waiter already knows. Control stays available for the cases that are actually different.
That sounds small. It is a sequencing decision. If we start by migrating components, or by redrawing headers, or by rewriting Android, we spend a year not touching the Golden Task.
I said no to:
A Compose rewrite. Out of scope, and it would freeze take-order while we rebuilt the house.
Copying a legacy grid because some staff missed it. Nostalgia is a signal (they want fewer trips off the screen), not a spec.
Making the visual unification of headers the story. Consistency helps. It does not take the order.
Shipping another confirmation. Empty and unresolved states are design bugs in a speed-critical flow.
The sequence I argued for:
1. Change how an order starts (the happy path).
2. Pull search, the stepper, and frequency-based navigation into the same Golden Task — as product, not as design-system debt on the side.
3. Define a real start for counter service so the metric exists there too.
The problem is a Golden Task
On table service, six administrative steps sat between opening the app and the first product: order name, covers, tables, linked reservation, save, course folder. None of those steps is why they opened the app. On counter service, the start was undefined. That made it easy to “improve” the wrong place and impossible to prove it.
Table View flow diagram
Table View. The Staff move is not fewer screens for their own sake. It is putting the first product first.
Field, not opinion
The same patterns showed up across hotels and countries:
Too many screens to add a drink.
An “open order” step that adds nothing when a table never has two orders.
A revenue-centre confirmation on every new order.
Quantity changes that felt slower than they are.
Search that needed near-exact text.
Staff who preferred a legacy POS where everything lived on one grid.
3:30
A simple one-person order, timed in live service.
That number is proof of pain, not a KPI. I would not use it as a before/after. I used it to stop the conversation about whether this was “just polish.”
Four root causes diagram
Four root causes. This is the diagnosis I used to keep the work from turning back into tickets.
The design is the constraint
A POS used every service, for years, is not a consumer app. A control that moves is not delight. It is retraining. Time is the product. Familiarity is a constraint, not a lack of ambition.
Principles I held as non-negotiable:
Speed of take-order beats every other aesthetic argument.
Change has to be incremental. Expert users operate in automatic. We earn each shift in the model.
Tap targets >= 48px. Live service, motion, one hand, no precision.
Legacy -> design system is a product migration, not a hygiene ticket.
Craft, with reasons:
One tap starts the order. Covers default from table capacity — the system already knows. A name is generated. The waiter is not asked to re-describe the table they are standing at.
“Configure” is an escape hatch, not the happy path. Power stays. It stops blocking the first product.
The revenue-centre selector lives with products, and it always shows a resolved value. An empty “–” in the header is a question in the middle of service.
We do not rebuild a nostalgic grid. The job underneath that complaint is frequency: what this waiter sells, first — not the menu’s folder tree.
What I would still push next (same initiative, not a new one):
Search that forgives partial input.
A stepper designed for speed, not for a form.
A start event for counter so Time to Take Order exists there.
Navigation by frequency, once the start is out of the way.
What shipped first, on purpose
The first slice is the bet made tangible: start an order in one tap, with defaults, on table service. Configuration remains for people who ask. Revenue centre is always resolved.
Shipping this without search, stepper, or counter-start is not incomplete thinking. It is Staff sequencing. The first proof has to be the Golden Task, on the stack we actually ship (Java/XML), not the stack we wish we had.
How I would defend it
Goal -> Time to Take Order on the happy path
Leading -> Taps and screens from open to first product. Drop-off at each mid-point.
Business -> The group that paused rollout comes back.
Note: No aggregated baseline yet. I will not invent a percentage. The honest Staff move is to instrument the funnel we already have, then publish the delta.
Time is the product
The work I want to be hired to do is this: take a messy operational surface, name the one task that justifies it, attach it to a real business risk, and change it without breaking the people who already live in it.
Results for this slice are still landing. The argument is already the one I would walk into a Staff loop with.