Social Media Marketing
All systems deisgn ready and shipped to development
My Role: UX Contributor — User Flows, Wireframing, Prototyping, Social Media Graphics, Print Designs
Client: Qatar-based hospitality client
Platform: Customer-facing mobile app, web-based booking flow, 3-tier management system (Super Admin, Merchant, Manager panels) Timeline: 3-month design engagement (1 month research and wireframes, 2 months dev integration feedback loops)
Status: Designs shipped to development
Context
TableBuddy was conceived during the 2020 pandemic when contactless dining became a market need rather than a feature preference. The product was a complete dining platform covering table discovery, reservation, in-app menu ordering, guest invitation, contactless payment, and post-experience review. The client (Rakesh and Ryan) had an initial app design that we significantly expanded and improved when approached for branding work. The platform required not only a consumer-facing mobile experience but a 3-tier management system for restaurant operators.
The Problem
Post-pandemic dining had fundamentally changed user expectations. Customers wanted to book, order, and pay without physical menus or cash handling. Existing restaurant booking apps (OpenTable, Resy) handled reservations but not the full in-dining experience. The management side was equally fragmented: restaurant managers used separate systems for reservations, orders, and analytics. TableBuddy needed to unify the complete dining journey on both sides.
My Role and Constraints
I was a UX contributor on this project under senior design direction. My contribution covered user flow development, wireframing across the mobile app and management panels, prototyping for client presentations, and social media graphics and print designs. The most significant constraint was the development team in India who ultimately did not follow the wireframe designs, which triggered nearly two months of feedback loops to integrate the planned features into the live build.
Research and Discovery
We researched the pandemic-period shift in dining behaviour and the adoption of QR code menus and contactless payments in markets across GCC, UK, and US. Competitive analysis covered OpenTable (reservation focus), Zomato (discovery focus), and restaurant-specific ordering apps (Toast, Square). The gap: no single platform covered the complete journey from discovery to post-meal review for the customer, and no management system unified all three operational tiers (super admin overseeing the platform, merchant managing the restaurant, manager handling daily operations).
Key Design Decisions
Decision 1: Table-first discovery over restaurant-first discovery
Standard booking apps show restaurant listings then ask for a table. TableBuddy led with a visual floor plan where users could see table availability and positioning (indoor, outdoor, non-smoking) before committing to a restaurant. Reasoning: for group dining, table selection is a social decision as much as a restaurant decision. Showing the table first rather than burying it in a booking flow gave users agency over the social aspect of their experience.
Decision 2: Guest invitation integrated into the booking flow, not post-booking
Guest invitations were originally designed as a post-booking feature. We moved them into the active booking flow so the host could invite guests while selecting the table. Reasoning: the social context of the event (who is coming) should inform the table selection (how many seats, which area). Separating invitation from selection created a flow that required users to complete booking before they had confirmed their guest list.
Decision 3: 3-tier management hierarchy as separate interfaces rather than role-filtered views
The Merchant Panel (restaurant owner), Manager Panel (daily operations), and Super Admin Panel (platform oversight) were designed as architecturally separate interfaces sharing a common design system rather than a single tool with role filtering. The reasoning mirrors the TrimSlim decision: each role's primary question is so different that a shared interface would compromise all three.
The Solution
TableBuddy delivers a complete contactless dining experience. The customer mobile app covers: restaurant discovery with filter customisation (cuisine, meal type), floor plan-based table selection, guest invitation via email or SMS with GPS location, menu viewing and in-app ordering, contactless check-out with payment, and post-experience review. The web management system covers: real-time reservation and floor plan management (Merchant), daily operations and order management (Manager), and platform-wide oversight with business analytics (Super Admin).
Outcome and Impact
The designs were shipped to the development team. A 2-month feedback and integration period followed where I provided continuous support to ensure the planned wireframe features for the web panels were correctly implemented in the live build. The development team based in different nation had diverged from the designs during build, and the feedback loops were required to realign the live product with the designed experience.
Reflection
The TableBuddy engagement taught me the importance of developer alignment as a design deliverable, not an afterthought. Shipping wireframes is not the end of the design process when you have a remote development team unfamiliar with the interaction patterns you have designed. The two months of feedback loops were recoverable but preventable. In subsequent projects, I invested more time in annotated handoff documentation and developer kickoff calls before build started.
Disclaimer: The project discussed herein was undertaken as a part of the Little Studio team. The rights to this project are jointly owned by the client and the studio. This case study is presented solely to showcase my individual contributions to the project.
