2024
Suzuki Motorcycle India Pvt Ltd
Suzuki Ride Connect
My Role
Solo Product Designer — Research, IA, Interaction Design, Handoff
Platform
B2B SaaS · Desktop · Mobile
Scope
4 Interconnected Products
Project Duration
~4 months (end-to-end)
01 - OVERVIEW
What is Zautae ?
Zautae is not another food delivery app. It's a full-stack restaurant operating system purpose-built for small and mid-sized restaurant owners in cities where Swiggy and Zomato charge high commissions but offer little operational control in return. The product covers four interconnected touchpoints: a customer-facing ordering app, a restaurant partner app for floor and kitchen staff, a delivery partner app, and an admin dashboard for managers and owners.
As the product designer, I owned the full product design lifecycle — from field research and persona mapping to design system creation and dev handoff — across all four modules simultaneously.
02 - CORE PROBLEM
Validating the problem before designing the solution
The brief initially sounded like "build a restaurant order management app." Before any wireframe, I spent three weeks understanding why existing solutions weren't working for this specific user group.
Research Methodology
Shadowed operations at 6 restaurants in Hosur during peak lunch & dinner hours
Conducted 14+ semi-structured interviews with owners, waiters, and delivery partners
Reviewed WhatsApp order threads, handwritten KOT slips, and Excel billing files restaurant owners actually used day-to-day
Mapped a full day-in-the-life for each stakeholder type before touchpoint analysis
Tested 3 competitor apps (Swiggy for Business, Petpooja, and a local POS) with actual restaurant staff — watched them fail at basic tasks
Sanjay Mahadev, Restaurant Owner, Hosur
Christopher, Restaurant Owner, Hosur
Sanjay Mahadev, Restaurant Owner, Hosur
Day-in-the-Life — Restaurant Owner:
6:30 AM
Checks three platforms (Swiggy, Zomato, direct calls) to plan ingredient procurement. No consolidated view exists. Often overestimates or underestimates stock.
11:30 AM – 2:00 PM (Peak)
Orders flood in across channels. Staff shout across the kitchen. Handwritten KOT slips get lost. Online orders go unacknowledged for 4–7 minutes on average. Two Zomato orders were cancelled last week — penalty charged.
9:00 PM (Close)
Manually adds up day's cash + UPI into a notebook. Swiggy settlement takes 7 days. No visibility into which items sold most. Can't plan tomorrow's prep intelligently.
03 - USER PERONAS
Understanding Three people. Three very different relationships with technology.
Rather than building abstract marketing personas, these are composite profiles grounded in the field research — real archetypes that shaped specific design decisions throughout the project.
04 - USER JOURNEY MAPPING
Before & after Zautae — across a typical lunch rush
Mapping the journey before Zautae revealed that the pain wasn't in any single touchpoint — it was in the disconnected handoffs between them. The redesigned flow eliminates five distinct friction points.
05 - IDEATION & EXPLORATION
Evaluating different approaches based on research insights
Before committing to a direction, I mapped three fundamentally different product approaches and stress-tested each against our research findings. Here's what I explored — and why two were abandoned.
Rejected
Approach A: Super-App Aggregator
Build a Swiggy-like marketplace that onboards multiple restaurants and competes head-on with aggregators on the consumer side.
Requires massive demand-side investment before supply-side can benefit
Doesn't solve operational problems inside the restaurant
Puts us directly in an unwinnable CAC war
Partially Used
Approach B: POS-First Tool
Build a best-in-class POS and billing system (like Petpooja) with add-on delivery integration.
Good for billing, but doesn't address delivery, customer acquisition, or loyalty
The "add-on" delivery integration creates the same fragmentation we're solving against
Core concept of POS integration was absorbed into the Admin module
Rejected
Approach C: Modular Ecosystem
Build a fully integrated, four-app ecosystem where each module is standalone but operates as one unified backend. Restaurant owners get the whole stack or can start with one module.
Solves operational chaos at every touchpoint simultaneously
SaaS subscription model keeps commission costs near-zero for restaurants
Modular entry = lower friction for onboarding skeptical owners
Key Trade-off Made
Approach C required designing four separate apps with consistent design language but different interaction models — customer-facing, staff-facing, rider-facing, and admin-facing. This multiplied design complexity significantly. The decision was justified by the insight that fragmented tools were the core enemy, and the only credible solution was a unified platform that owns the entire restaurant workflow.
06 - PRODUCT DESIGN WALKTHROUGH
Four modules. One ecosystem. Every decision explained.
Here's a detailed breakdown of what each module does, the specific design decisions behind key features, and why those features exist in the form they do — not just what they look like.
The ownership shift the Admin Panel was designed to create
When a restaurant uses Swiggy or Zomato, the platform owns the customer data, the order history, the reviews, and the analytics. The restaurant gets a settlement and a PDF. Zautae's Admin Panel was explicitly designed to reverse that — the owner sees customer analytics, order trends, staff performance, and revenue splits in real time. They own the data. That's not a feature. That's the product.
07 - PRODUCT DESIGN DECISIONS
Design choices tied to business & user outcomes.
The real problems no brief document mentions.
Instead of positioning the project as highly complex or extreme, the challenges were more practical and context-driven:
Most restaurant owners and staff were comfortable with basic smartphone usage (calls, WhatsApp), but not with structured business tools. The product had to feel immediately usable without training.
Restaurants were already using Swiggy and Zomato for orders. The challenge wasn’t replacing them instantly, but gradually introducing an alternative workflow that felt reliable.
Orders were coming from multiple sources (calls, WhatsApp, aggregators), but there was no single system. The difficulty was in simplifying without disrupting their current habits too much.
Staff operate in fast-paced environments, especially during lunch and dinner. Any added complexity in the interface would directly slow them down.
English-heavy interfaces were not always comfortable for all users. Labels and flows needed to be simple, clear, and in some cases bilingual.
Owners were cautious about adopting new systems unless they clearly saw value in terms of saving time, reducing errors, or improving earnings.
What Zautae still doesn't solve — and what I'd do next.
Honest reflection on what the current design leaves incomplete. These aren't failures — they're deliberate deferrals based on MVP scope, but they represent the most important design work still ahead.
Faster Average Delivery
Measured: avg. order-to-doorstep time. Before: 47 min. After: 31 min. Enabled by smart order clubbing & zone-based routing. Sample: 1,200+ delivery events over 90 days.
Reduction in Support Calls
Measured: inbound support tickets per restaurant per week. Before: avg. 5.2/week. After: avg. 3.1/week. Primary drivers: auto WhatsApp order status updates + OTP verification reducing delivery disputes.
Staff Training Time
Measured: time to complete first full order cycle unaided. V1 baseline: 12–15 min. Post-redesign: avg. 4.5 min. Tested with 11 new restaurant staff members across 3 locations.
Annual Commission Saved
Modeled: based on pilot restaurants shifting 30% of online orders to Zautae. Compared against 27% Zomato/Swiggy commission on equivalent order volume. Direct financial impact the design was built to enable.
Metrics, credibly stated.
These numbers come from pilot deployment data collected across 8 partner restaurants in Hosur over a 90-day post-launch period (N=8 restaurants, ~340 daily orders combined). They are directional, not statistically conclusive, and should be interpreted accordingly.
Unsolved Now
Customer acquisition & discovery
Zautae restaurants still need Swiggy for new customer discovery — Zautae has no organic network effect yet
No social proof or review system within the app
Restaurant listings lack the food photography infrastructure Swiggy provides
Phase 2 Roadmap
AI-assisted menu & inventory
Predictive stock alerts based on historical order patterns
Smart menu pricing recommendations by time-of-day or weather
Auto-detect when an item should be 86'd before running out
Phase 3 Roadmap
Multi-branch & franchise mode
Cross-branch inventory consolidation for restaurant chains
Regional performance benchmarking across 5+ locations
Staff scheduling & shift management integrated into Admin panel
Design Debt
Accessibility & deeper localization
Accessibility audit not yet conducted; WCAG AA compliance unverified
Voice input for order entry (critical for low-literacy users) was scoped out — would meaningfully improve adoption
What I actually learned building this.
The most impactful design decision I made on Zautae wasn't a UI choice. It was convincing the team to build a product instead of a service — and then designing every screen to prove that a non-technical restaurant owner in Hosur could run it completely on their own.
Research in the real environment beats any user interview
Watching a waiter lose a KOT slip during a lunch rush told me more about the problem than 3 interviews did.
Simplicity is an active design decision, not a default
Every complex feature we absorbed into the backend required deliberate design effort to surface as a simple action. That work is invisible — which means it worked.
Designing for low digital literacy forces better design for everyone
The constraints — large touch targets, icon labels, single CTAs, offline support — made the apps better for all users, not just first-timers.
Business model and design are not separate concerns
The choice to be SaaS-first (vs. commission-based) directly determined what the UI needed to enable. Designers who understand the revenue model make better product decisions.
Parallel multi-product design requires shared systems, not shared aesthetics
The four apps look similar because of a shared component library — not because I applied a visual style uniformly. The distinction matters for scalability.
