The work
A complete ordering experience, engineered as one product.
A restaurant-ordering experience appears simple from the outside: find a restaurant, choose something to eat, and place an order.
Behind that simplicity is a much harder product problem.
The interface must understand whether a restaurant is available, whether it delivers to the customer’s address, which fulfillment methods are active, what currency the order uses, which products can be customized, and what should happen when the backend rejects an order. It must also keep the customer oriented as they move between discovery, checkout, confirmation, tracking, order history, and their account.
We set out to build a complete ordering experience for Sync, connecting interface decisions, data and navigation from the first restaurant search to the final order update.
The resulting work covered restaurant discovery, menus, product and offer details, fulfillment, cart and checkout, delivery addresses, confirmation, tracking, Orders, Profile, authentication, and rating.
A coherent experience is not one where every screen looks identical. It is one where every step tells the same truth.
01 · The first problem
The first problem was not visual.
The work began around restaurant discovery, where an interface can only be as honest as the operating data beneath it.
Sync’s landing page and restaurant-management tools already had a recognizable identity: warm surfaces, editorial typography, rounded controls, restrained elevation, and orange accents. The customer listing did not yet feel connected to that system.
Restaurant cards placed names, operational information, delivery details, minimum orders, and distance directly over photography. The result could look dramatic, but it was harder to scan, particularly when the underlying image was visually busy.
But before redesigning the cards, we found a more fundamental problem. The restaurant API could return opening hours as an array of daily records. The customer application expected only a day-keyed object. A restaurant could therefore be returned successfully by the API and still fail to render in the interface.
The model was updated to accept both supported opening-hours formats and the time aliases already used by the discovery endpoint. Invalid entries could be ignored safely instead of causing the complete listing to fail.
This pattern continued throughout the project. Whenever visual polish conflicted with authoritative data, the data won.
02 · One journey
Designing the journey as one product.
Each stage has its own requirements, but none of them can feel isolated from the stage before it.
We mapped the customer experience as a continuous sequence:
- 01Discover
- 02Restaurant
- 03Product
- 04Fulfillment
- 05Checkout
- 06Confirmation
- 07Tracking
Discovering the right restaurant
Restaurant discovery needed to answer practical questions quickly: Which restaurants are available? Which ones deliver to my location? Are they open now? What will delivery cost? Is there a minimum order? How far away are they?
Photography remained prominent because food and restaurant identity are inherently visual. Operational information, however, moved into a separate readable surface rather than competing with the image.
Restaurants disabled at either the restaurant level or their public-listing level were removed from discovery entirely. Restaurants that were temporarily closed but still available remained visible and could communicate their next opening state.
This distinction mattered. “Closed right now” and “not accepting customers through Sync” are not the same condition, and the interface should not pretend that they are.
Understanding the restaurant
Opening a restaurant page should feel like a continuation of discovery. The page establishes the restaurant’s identity through its cover image, logo, availability, ordering modes and essential operational details.
Search was redesigned to provide a clear starting state and an easy way back. A focused category selector replaced the sequence of expanded sections. Only the selected category’s products were built and displayed, keeping the menu manageable.
Menu items used image-led rows with clear product information and distinct actions for viewing details or adding to the cart. Products that were unavailable stayed visible but were clearly disabled rather than appearing actionable.
03 · From choice to order
From a choice to a valid order.
Product detail and checkout must represent the same information that eventually enters the cart and reaches the restaurant.
Choosing and customizing a product
Products could include descriptions, ingredients, additions, removals, notes, quantity, discounts, and calorie information. These options were presented in one continuous experience instead of splitting customization across competing layers.
Calories appeared only when an authoritative positive value existed. The interface no longer inferred calorie information from unrelated preparation data or displayed a default value.
Offers received the same treatment. Placeholder images, hard-coded product rows and unsupported marketing claims were removed. Each offer displayed its actual products and could be added to the cart while preserving the correct restaurant context.
The interface could still be persuasive, but it could not fabricate information to achieve that.
Turning intent into a valid order
Checkout is where a polished customer experience meets operational reality. Customers may need to select delivery or in-restaurant ordering, choose an address or table, provide a phone number, authenticate, edit product customizations, and resolve validation problems before an order can be accepted.
The fulfillment selector was simplified into one compact surface rather than two oversized competing cards. Cart editing, order notes, pricing, saved addresses, and the final action were brought into one readable flow, with a wider two-column layout used when enough screen space was available.
Technical errors around delivery and pickup were translated into guidance in the customer’s language. Checkout did not expose backend field names or internal exception messages.
04 · After checkout
Trust does not end when an order is submitted.
Confirmation, tracking, order history, and Profile need to remain part of the same customer-facing product.
Confirmation presented one clear summary and one continuous receipt using the real restaurant identity, fulfillment method, products, customizations, charges, taxes, currency, and final total.
Order tracking remained within the customer-facing Sync product. It no longer transferred customers to the restaurant-partner interface, and shared tracking routes did not place customer phone numbers inside the URL.
Orders, order details, rating, cancellation, and Profile were then brought into the same journey. A customer could move from a restaurant to an order, from an order notification to its details, or from Profile to their history without encountering a new navigation model each time.
Consistency without sameness
The customer experience borrowed from Sync’s restaurant-management design language: warm cream backgrounds, orange accents, editorial headings, soft translucent surfaces, restrained elevation, rounded controls, and tactile press and hover responses.
Each stage had different priorities: inviting imagery for discovery, clarity at checkout, visible progress during tracking, and a personal profile without fabricated avatar data.
That difference became especially clear during the restaurant-page redesign. The first design pass placed too many sections inside elevated white surfaces. Although the individual components were consistent, the complete page felt like a wall of widgets.
We reduced the number of containers: announcements became simple strips, restaurant imagery formed a collage, products became rows separated by subtle lines, and secondary information sat naturally within the page.
A design system should create relationships between elements, not force every element into the same container.
05 · Behind the screens
Continuity lives behind the screens.
Some of the most important improvements happened behind the interface, making the visible experience more consistent and dependable.
The original address experience existed in different forms depending on where the customer entered it. Homepage location, Profile addresses, and checkout could drift in behavior.
These were consolidated around one shared address form and a canonical full-page editor. Signed-in customers selected real server-backed addresses, while temporary local address identifiers remained limited to the explicit guest flow.
A successful address creation also used a stable request identity so a retry after a lost response would not silently create duplicates.
Navigation needed structural work too. Static routes such as /order-details, /rating, cart, and other customer pages originally competed with a catch-all restaurant route. In some cases, the router interpreted a path such as /order-details or /rating as though it were a restaurant identifier.
Static customer routes were moved ahead of the restaurant route while valid restaurant deep links remained supported. Back behavior was standardized using a pop-or-fallback rule. Direct links, browser refreshes, and normal in-app navigation could then return customers to a predictable destination instead of relying on hard-coded routes.
06 · Language and performance
Designing Arabic and English together.
Arabic was not treated as a translated version of the English interface.
The customer design system used separate typography roles for each language. English used Outfit for interface text and Playfair Display for selected editorial headings, while Arabic used its own distinct, legible type role.
Direction affected more than text alignment. It influenced the position of Back and Forward actions, arrow direction, control order, carousel movement, card affordances, search behavior, and mixed-language campaign and product content.
Material icons were allowed to mirror semantically with text direction instead of being manually replaced for Arabic. This avoided double-mirroring, where an icon could move to the correct side of the screen but point in the wrong direction.
English restaurant or campaign copy could also remain left-to-right inside an Arabic route while the surrounding navigation stayed right-to-left. That prevented punctuation, truncation, and ellipses from appearing on the wrong edge.
Motion followed the same accessibility standard. Entrance effects, hover, press feedback, carousel animation, parallax, and image fades resolved immediately when the platform requested reduced motion. Automatic carousel advancement was disabled in that mode as well.
Keeping the experience responsive
A coherent journey still fails if it feels heavy. The restaurant listing retained its lazy CustomScrollView and sliver-based structure rather than being rebuilt as one eager page-sized column. Restaurant cards continued to be constructed only when needed.
Image decoding was bounded near the rendered size. Key campaign artwork and the first restaurant rows were warmed after the first frame in small batches, allowing the interface to prepare upcoming content without making the initial frame compete with additional work.
Press interactions relied on transforms rather than triggering layout changes. Dominant image colors were extracted from small cached samples instead of repeatedly scanning full-resolution covers.
These were performance-conscious decisions, but we deliberately avoided claiming that performance improved without a comparable measurement from the same device and build mode.
07 · What was verified
What we verified, and what still needs measurement.
The result should distinguish what was designed, implemented, tested, and deployed from what still requires production usage and post-release measurement.
The release checks passed 44 focused tests covering navigation, cancellation, availability, dialogs, interface components, cart behavior, menus and products, order details, addresses, phone numbers, restaurant visibility and operational footers.
A release-mode Flutter web build completed successfully, and the exact source revision was deployed and verified through its live release marker. The journey was also exercised in real browser sessions across English and Arabic, including discovery, restaurant access, menus, Profile, phone capture, Orders, order details, addresses, fulfillment, confirmation, tracking, and rating states.
At the time of delivery, the full repository suite also contained eight unrelated, pre-existing failures. These remained documented and were not attributed to the new changes.
We can therefore say what was designed, implemented, tested, and deployed. We cannot yet say that engagement increased, restaurant-card click-through improved, or customers completed more orders. Those conclusions require production usage and post-release measurement.