Designing Togetherness.
A virtual party experience where the food, the people, and the moment all arrive at the same time.
87%
Growth potential
50%
Error reducation
20%
Order value fit
6/10
Social shares
OVERVIEW
Treatsure was built during COVID-19 in India, when celebrations that used to happen around a table got compressed into a Zoom grid. People were missing the small things that make a gathering feel like a gathering: passing plates around, eating the same meals, and the clinking of glasses that requires everyone to actually be holding one.
Technically together. Actually alone.
Treatsure was designed to close that gap.
Treatsure synchronizes food delivery across a group so everyone's meal arrives at the same time and layers in a virtual party experience around it. The goal was simple but ambitious: make an online celebration feel as warm and effortless as being in the same room.
Timeline
Oct 2021 – Oct 2022
Team
Lead designer
Visual designer
UX designer
My Role
UX Designer :-
Research, User Flows, Rapid Prototyping, UI & Interaction Design.
Website
PROBLEM
Celebrations moved indoors, but the experience didn't.
Online dating is growing, but meaningful connections and privacy remain major challenges.
01
Life moved indoors.
When COVID hit India, daily life moved indoors almost overnight. Celebrations that used to mean food, noise, and shared experiences got reduced to a video call where everyone sat in a different kitchen eating different things at different times.
03
The real gap.
No existing product recreated the feeling of sitting around the same dining table while being miles apart.People could talk together. People could order food. But nobody could share a meal together.
02
The available tools didn't bridge the gap.
Apps like Zoom, Houseparty, Rave, and Evibe were great for getting people on a call, but they had no relationship with food. Apps like Swiggy and Zomato could deliver food, but every order was treated as an isolated event—one person, one address, one delivery window. Nobody was solving the actual problem.
"How might we bring people together not just on screen, but through food that arrives at every home at the same time?"
A gap existed between casual dating and traditional matchmaking.
Users wanted meaningful connections without sacrificing privacy or flexibility.
Casual Dating
Fast matches. Surface level connections.
Personality-first. Privacy-first.
Marriage Oriented
Serious intent. Limited flexibility.
No solution balanced connection, privacy, and authenticity.
RESEARCH
User research results & insights
We began by validating the PRD with stakeholders, surfacing intent, constraints, and aligning on goals. This was followed by analyzing competitors to identify gaps and opportunities.
01
Stakeholder alignment
Started with a PRD walkthrough and stakeholder interviews to align on what we were actually building. The shift in framing here mattered: Treatsure wasn't a food delivery app with social features bolted on. It was a connection product where food happened to be the medium. Every downstream decision flowed from that.
02
Competitive analysis
a. Houseparty / Zoom / Rave / Evibe.in → enabled conversation, but not dining
b. Swiggy / Zomato → delivered food, but treated each order as isolated
c. Gap Identified → no one recreated the shared dining table.
03
Target audience & constraints
b. Professionals doing remote team celebrations
c. Families marking birthdays and festivals across cities
d. Large groups of 50+ for events
Qualitative research
9 in-depth interviews with users who had hosted or attended virtual celebrations during the pandemic.
The biggest finding: the problem was emotional, not logistical People weren't frustrated about food being late - they were frustrated about food being separate. Eating different meals at different times, even on the same call, made the gathering feel like an isolated meeting.
Quantitative research
A 60+ person survey confirmed the patterns:
• Missed eating at the same time as the people they were on call with
• Wanted variety across the group without coordinating five separate orders
• Found online celebrations fragmented - the food, the call, and the experience all lived in different places
Introducing our persona
Scenario: User wants order food for a virtual party (multiple people and customize it too)
Journey map
Scenario: User wants order food for a virtual party (multiple people and customize it too)
User flow mechanics that mattered
Three design decisions did the heavy lifting:
Real-time order summary panel.
A persistent right-hand panel that updated as users added items and quantities. Visibility of system status reduces mental load.
Per-guest assignment UI.
Users could create "guests" inside the order and either assign items to a specific guest or mark them as shared. This solved the single biggest failure mode in existing flows - losing track of who ordered what.
Synchronized scheduling CTA.
Once items were finalized, the interface asked for a party start time and surfaced a single suggested delivery window built from partner ETA estimates.
The stepwise structure prevented the single-page overwhelm we'd seen in formative tests.
Information architecture
We built the IA around how people actually plan events:
decide occasion → choose headcount → choose food → confirm logistics
That sequence matched the user's mental model and removed friction at every step.
PRODUCT
The final app is built around four ideas working together.
Online dating is growing, but meaningful connections and privacy remain challenges.
1.
Group ordering across multiple restaurants.
A single order can pull dishes from more than one restaurant, so the person who wants biryani and the person who wants pasta and the person who "just wants something light" can all get exactly that, without anyone having to compromise, coordinate five separate transactions, or appoint themselves the group's unofficial food secretary.
2.
Per-guest customization.
Each item can be assigned to a named guest in the order or marked as shared. Dietary preferences, customizations, and quantities live with the guest, not buried in a single combined cart where nobody can remember who asked for no onions.
3.
Synchronized delivery window.
After items are confirmed, Treatsure consolidates the ETAs from every partner restaurant into one suggested delivery slot - so everyone's food shows up at roughly the same moment, so the party doesn't start with half the group watching the other half eat.
This was the core promise of the product, made into a feature. Not "food delivery for groups" but "the moment everyone lifts their fork together.
Visuals of Chance
TESTING
Three iterations, three numbers moved.
Formative testing with 8 participants revealed three friction zones. Each one got a targeted design move and a measurable outcome.
OVERVIEW
8 participants
3 iterations
Moderated format
TASK LIST
Iteration 1 - Checkout complexity
Problem:
Users lost track of who had ordered what once the group grew past 3–4 people. Many abandoned at checkout.
Design move:
Added always-visible "Get a Quick Call" and WhatsApp fallback CTAs at the points of highest friction.
Outcome:
62% to 87%
checkout completion errors dropped ~50%
Iteration 2 - Support discoverability
Problem:
When users got stuck mid-order, they couldn't find help quickly enough - and bailed.
Design move:
Step-wise customization flow with a persistent order summary panel on the right so the full state of the order is always visible.
Outcome:
Confidence ↑
post-flow confidence scores rose in subsequent rounds
Iteration 3 - Decision fatigue
Problem:
Too many menu and meal options at once caused decision paralysis, especially for group hosts.
Design move:
Introduced curated meal packages as discoverable cards, with visible upsells embedded inside each package.
Outcome:
+20% AOV
projected order value 6/10 shared celebration page
IMPACT
The redesign moved real numbers on both sides.
More importantly, it reframed the product itself, from "food delivery for groups" into a category that didn't really exist before: synchronized social dining.
01. FLOW -
Did the redesign actually fix the flow?
Checkout completion
+25 pts
Before(V1)
62%
After(V2)
87%
~50% fewer
checkout errors, group state was always visible, so users stopped losing track of what they'd added.
02. REACH -
Did users want to share what they made?
6 / 10
users shared their celebration page with friends
A 60% organic share rate is the basis of a referral loop, and a signal that the synchronized-dining moment was worth talking about.
03. BUSINESS -
Did the bet pay off?
+20% AOV
projected lift in average order value from curated packages and visible upsells
Validated a new category
synchronized multi-restaurant group dining, something competitors weren't structured to deliver
Scoped a phased roadmap
protected launch speed while leaving room for advanced features later
Built a referral loop
the shared celebration page became an organic growth lever, not just a confirmation screen
What we said no to, and why.
Three explicit trade-offs that protected launch speed without limiting future depth.
Engineering cost vs. user value:
True real-time per-rider tracking was deferred. We shipped an MVP scheduling engine that combined partner ETAs into one suggested delivery window - enough to deliver the synchronized experience without waiting on deeper ops integration.
Accessibility vs. aesthetics:
Prioritized contrast and keyboard navigability while keeping the festive illustrative style. Brand and inclusivity together, not traded against each other.
Complexity vs. speed-to-market:
Advanced features like per-guest dietary rule propagation across restaurants were pushed to the roadmap. The IA and data model were built to support them later without requiring rework.
LEARNING
What This Project Taught Me
Lessons learned about user behavior, product strategy, and designing within constraints.
The problem was emotional, not logistical.
The biggest reframe of the project. Users weren't asking for faster delivery or cheaper food - they were asking to feel like they were eating with someone, not just on a call in parallel. Once we stopped designing a delivery flow and started designing a togetherness flow, every decision got easier.
Stepwise beats a single page when the flow is complex.
Our early sketches tried to fit the whole order experience onto one screen. Formative tests killed that idea fast - users were overwhelmed, lost track of guests, and abandoned the flow. Breaking the flow into clear steps with a persistent summary panel was the single biggest unlock for checkout completion.
Persistent state is a confidence feature.
The right-side order summary told users at every step exactly what the order looked like, who it was for, and what it would cost. That visibility is what moved completion from 62% to 87%.
Curated > infinite when decision fatigue is the enemy.
The instinct in food apps is to surface more variety. For Treatsure, the opposite was true. Curated packages performed better than open menus for group hosts already managing enough variables.
Trade-offs are part of the design.
Real-time rider tracking, advanced dietary rules, per-restaurant promo logic - we said no to all of them at launch. Naming the trade-offs explicitly, and protecting future flexibility through the IA and data model, was as much a design decision as anything on the screen.
