Controls the business behind the operation—from performance and staff to products, tables, devices and configuration.
Sahebeh BabaeiProduct Designer
Product Design · 2026
ATPOS
Built to run the restaurant. Designed to grow with the business.
RoleSenior Product Designer
Status+300 Screens & States
FocusRestaurant POS · B2B Product · Desktop Application · SaaS
A scalable B2B restaurant POS ecosystem connecting administration, ordering and kitchen operations through one consistent desktop experience.
Restaurant POSB2B ProductDesktop ApplicationSaaS
02 / THE PRODUCT
More than a POS
ATPOS is a scalable B2B restaurant POS system designed for restaurants, cafés and other food-service businesses. It connects ordering, table management, kitchen operations and administration within one desktop product. The platform is designed as a commercial product that can be offered through either a licensed ownership model with paid support or monthly and annual subscription plans with ongoing services.
03 / PRODUCT ECOSYSTEM
One system Three sides
The product was structured around three connected environments, each designed around a different operational responsibility.
Supports the daily front-of-house workflow across orders, tables, menu selection, reservations and payment.
Gives kitchen staff a focused view of incoming orders and lets them move each order from received to preparing to ready.
04 / DESIGN SCALE
Designed at scale
The final design grew into more than 300 screens and states across multiple modules, workflows and user roles. The goal was not to design hundreds of isolated interfaces, but to create a system that could remain understandable and consistent as the product expanded.
Complex underneath
Simple in use
Restaurant software has to handle considerable operational complexity while being used in an environment where speed, clarity and predictability matter every minute.The real design challenge was to support growing menus, multiple order types, different roles, reservations, large table layouts and future modules without making everyday tasks increasingly difficult.
THE DESIGN QUESTIONHow can growth stay simple?SCALABLEFASTPREDICTABLE
Structure
before screens
Before individual screens could work, the product needed a clear operational structure. Responsibilities, modules and system states were separated according to how the restaurant actually functions.
- AdminAnalytics · Staff · Roles · Transactions
- RestaurantProducts · Categories · Tables · Devices
- CashierOrders · Menu · Tables · Reservations
- KitchenReceived · Preparing · Ready
07 / SCALABILITY
Ready to grow
Scalability was treated as a product-design requirement from the beginning. Restaurant size, menu complexity and operational volume could increase without requiring a different interaction model.
08 / SELECTED FLOW
One journey, up close
From more than 300 designed screens and states, this case study focuses on one of the product’s core operational journeys: creating an order. It shows how different starting contexts converge into one consistent ordering experience.
09 / ORDER ENTRY
Start anywhere
Ordering does not begin from a single fixed screen. Staff can start a new order from the Orders workspace, select a table first, or begin directly from the Menu. These different entry points were intentionally connected to the same underlying order logic, allowing staff to work from their current context without learning separate workflows. Orders → Table → Menu → One shared ordering logic
10 / ORDER MANAGEMENT
Status at a glance.
The Orders workspace was designed as an operational overview rather than a simple list. Staff can quickly understand which orders need attention, where they are in the process and what type of service they belong to. Orders can be filtered by status and by service type, including dine-in, takeaway and delivery.
11 / TABLE EXPERIENCE
Tables with context
Tables were designed as operational objects rather than static floor-plan elements. Their state, capacity and location provide context before staff begin an interaction. Multiple floors or service areas allow larger restaurant layouts to remain manageable as the number of tables grows.
12 / MENU EXPERIENCE
Find, Configure, Order
The Menu workspace was designed for fast scanning while supporting a product catalog that can continue to grow. Categories, subcategories, search and sorting create several ways to reach an item without forcing staff through deep navigation.
13 / PRODUCT CONFIGURATION
Flexible when needed
Not every menu item has the same structure. Some products can be ordered immediately, while others require choices such as size or additional attributes. Configurable products can therefore carry their own options and pricing, while simple products remain simple. Additional decisions appear only when the selected product requires them. Pizza → Size → Small / Medium / Large → Individual pricing
14 / PRODUCT DECISION
Simplify the model
Add-ons were initially considered as product-specific configurations. While flexible, this would add extra rules across product setup, ordering, pricing and implementation. I proposed a simpler model: treating add-ons as independently manageable sellable items. This preserved pricing and ordering flexibility while reducing unnecessary complexity across both the interface and the underlying product logic. Less configuration. Cleaner ordering. Simpler logic.
15 / WHY SIMPLIFICATION MATTERED
Complexity on demand
The same principle shaped the ordering experience. Extra decisions are introduced only when they are relevant to the selected product. This keeps frequent actions fast while still allowing more complex products to support variations, quantities and additional choices.
16 / KITCHEN HANDOFF
From order to kitchen
Once submitted, the order continues into a deliberately simpler kitchen experience. Kitchen staff do not need access to the complexity of the ordering system—they need to see what has arrived and move it through clear preparation states. Orders progress from received, to preparing, to ready, creating a clear handoff back to front-of-house staff.
17 / MY CONTRIBUTION
Beyond the screens
As Senior Product Designer, my responsibility extended beyond interface execution. I translated a broad commercial product vision into a coherent desktop system across administration, ordering and kitchen operations. My work included structuring product areas and workflows, defining interaction patterns and system states, designing scalable product logic, resolving complexity and maintaining consistency across more than 300 screens and states. PRODUCT STRUCTURE UX ARCHITECTURE INTERACTION DESIGN PRODUCT DECISIONS SCALABLE SYSTEMS
18 / SYSTEM DESIGN
One product language
With hundreds of screens and states, consistency depended on reusable patterns rather than individual page-by-page decisions. Navigation, cards, forms, modals, order states and table states were designed to behave predictably across the product.
Clarity is the
designed result.
The completed design phase transformed a broad restaurant POS vision into a structured, development-ready product spanning administration, ordering and kitchen operations.
“Grow the system without making the experience harder to use.”