A handheld POS that fits in a server’s pocket.

In a restaurant running a traditional countertop POS, the same scene plays out all day: a server jots the order on paper at the table, walks back to the counter to queue and enter it, then walks back to confirm. At peak hours these round trips pile up and slow ordering, kitchen output, and table turnover — and the moment the network or power dies, that countertop terminal takes the whole restaurant down with it. Mobile POS exists to fix both: bring ordering and checkout to the tableside, and stay dependable when the network isn’t.

Mobile POS is built for trained restaurant servers working under real pressure: noise, time constraints, guests watching, standing, device in one hand. The design goal is therefore not “understandable at first glance” but operable by muscle memory after training, and error-free at peak hours — fixed control positions, shortest paths, guarded risky actions. That allows higher information density than a consumer product, and demands far stricter operational consistency in return.

• Benchmarked Toast GO — its always-accessible table checks, tabbed by payment status, became the key reference for order history
• Audited the desktop POS’s complete feature list: what must move to the phone, what stays behind
• Watched how staff actually hold devices in real restaurants — typically left hand holding, right hand operating, standing

We filtered by how often things happen at the table: ordering, checkout, and order-history management moved fully onto the phone, one tap away; low-frequency and complex functions deliberately stayed on the countertop POS. The cost is incompleteness — but Mobile POS was never meant to replace the terminal. It exists to perfect the part worth carrying: the lighter the device in a server’s hand, the faster the service at the table.

Mobile POS has a moment a countertop terminal never faces: at checkout, the device turns to face the guest. The audience flips instantly from a trained employee to an untrained customer — one choosing a tip and signing while the server stands right beside them. So the staff-facing side is optimized for density and speed, while the guest-facing payment and tip screens are deliberately minimal with unmistakable amounts — refined across multiple review rounds to avoid confusion or awkwardness in a socially loaded moment.

Office software assumes users can finish a flow uninterrupted; a restaurant floor is the opposite — mid-order, another table calls, the kitchen shouts, a guest changes their mind. Every core flow therefore had to be safely interruptible and resumable: unsubmitted orders hold their state, and servers pick up exactly where they left off instead of starting over.

In a high-pressure environment, the cost of finding information has to approach zero — so one color language runs through the entire system:

• Table states — open, dining, and overtime tables each carry a dedicated status color: a server reads the entire floor in one glance, no reading table by table
• Dish categories — seafood, drinks, and house specials each carry a dedicated color: in a grid of hundreds of items, finding a dish turns from reading into scanning — lock the color zone first, confirm the name second
• The number pad — outlined keys became solid color blocks, instantly readable as tappable

• Shortest possible operation path — no redundant steps
• Keyboards auto-invoke wherever input is needed
• Minimal thumb travel for one-handed use
• Deliberate friction for irreversible actions — Void and Discount require PIN verification: the one place designed to trade speed for safety
• Consistent button positions and states across screens

In the details, that meant drawers converted to modals for thumb reach, a Confirm vs. Done copy distinction, and a streamlined note-input path — small changes that decide whether a server can operate accurately in a hectic environment.

With dozens of screens to migrate, designing each page individually would have been slow and impossible to keep consistent. So I built a componentized design system:

• Component variants for buttons, inputs, modals, and list items — covering size, state, and use case
• Semantic color definitions so Light and Dark Mode share one component structure — no parallel design files to maintain
• Interaction rules baked into components — any new screen inherits the standards automatically, no designer discipline required

Screen design turned from “drawing page by page” into “assembling from components,” and design and engineering gained a single source of truth.