Overview
Be more than a tourist. Be an honoured guest.
Ritualy connects identity-verified travellers with Indian families who choose to open their wedding celebrations to outside guests. It is not a ticket to a performance and it is not a marketplace listing. It is an actual invitation, controlled entirely by the host family, with privacy and consent built into every layer of the experience.
Culture, shared on the family’s terms, not sold as a spectacle.
My role
I joined when Ritualy was still an idea about closing a gap.
Travellers wanted real cultural experiences, and Indian families with weddings to celebrate had no safe way to share them beyond their existing guest list. My job was to take that idea all the way to a developer-ready product.
That included:
- Framing the problem and defining what trust and safety needed to look like for two very different, equally cautious groups of people
- Running research: interviews with wedding-hosting families and culturally curious travellers, plus a look at existing platforms in adjacent spaces
- Mapping the verification, matching and booking flows for both hosts and guests
- Designing wireframes through to high-fidelity UI
- Running usability tests and iterating based on where trust broke down
- Preparing final files, specs and documentation for developer handoff
The hardest part
It wasn’t the interface. It was designing for a situation where the stakes are genuinely personal: a family’s wedding day, and a stranger being let into it.
From an idea to a working product
I didn’t start with screens. I started with the trust problem underneath the idea.
Ritualy started with a simple, slightly uncomfortable question: is it possible to let strangers into one of the most intimate days in a family’s life, without it feeling transactional or unsafe for anyone involved?
If that wasn’t solved, no amount of good UI would fix it. From there the process moved through research, flow mapping, prototyping and testing, with every round surfacing a new trust gap to close, whether that meant rethinking how much a host needed to disclose upfront, or how a traveller could prove they were genuinely respectful and not just curious for a photo.
By the end, the product wasn’t just a booking flow. It was a system built specifically to make two strangers feel safe enough to meet.
Key objectives
Four things the design had to protect.
- Give hosts complete control over who they let into their celebration and how much they share
- Make identity verification feel like a safety measure, not a bureaucratic hurdle
- Help travellers earn genuine access to a cultural experience, rather than simply paying for one
- Keep the entire exchange feeling like an invitation, never a transaction
01 / Problem and challenge
Real cultural access already exists. It just doesn’t feel safe, on either side.
Platforms already exist that let travellers attend real Indian weddings, some by literally selling tickets to the ceremony. That solves access, but it creates a new problem: it turns a deeply personal family event into something closer to a paid show, with little regard for how the hosting family actually feels about strangers walking through the biggest day of their lives.
Two problems, really:
-
For hosts
Opening their wedding to outsiders means opening their home, their family and their privacy, with no reliable way to know who is actually showing up, or why.
-
For travellers
Most paths to a real cultural experience are either completely closed off, or reduced to something that feels more like a staged tourist package than an actual invitation.
The core problem wasn’t “we need a booking platform for weddings”. It was that nobody had designed for the trust two strangers need before one lets the other into something this personal.
02 / Strategic shift
The opportunity wasn’t better access. It was better consent.
Early thinking treated this like a straightforward marketplace: list weddings, sell seats, done. But that model already exists, and it comes with real discomfort baked in. Hosts have almost no control once a ticket is sold, and travellers get an experience that has been priced and packaged rather than genuinely shared.
The shift happened when I stopped asking how we get more travellers into more weddings, and started asking how we make sure every single guest is someone the host actually wanted there.
Three connected challenges
Every decision after this point had to hold up against all three at once.
-
For hosts
How might we let families open their celebrations to outsiders without giving up control over their own privacy and safety?
-
For travellers
How might we help travellers earn genuine access to a cultural experience, instead of simply purchasing a seat?
-
For the platform
How might we design a system where both sides trust each other before they have ever met?
03 / Understanding the users
Two sides, needing very different things from the same platform.
The families hosting, and the travellers hoping to attend. I approached this through:
-
Interviews with hosting families
To understand what would actually make them comfortable inviting a stranger, and what would make them say no immediately.
-
Interviews with travellers
People who had sought out cultural experiences abroad before, to understand what authentic meant to them versus what usually gets marketed as authentic.
-
Research into existing platforms
In the wedding-tourism space, to understand what problems they had already solved and where they were still creating discomfort for hosts.
The biggest surprise wasn’t what travellers wanted. It was how much hosts’ hesitation had nothing to do with money, and everything to do with control.
04 / Competitor analysis
Three platforms, each standing in for a different piece of the trust equation.
I chose competitors that each represented a different piece of what Ritualy needed to solve, not just other travel platforms.
-
Join My Wedding
The closest direct precedent, an existing platform where travellers can pay to attend real Indian weddings. Studied because it proves demand exists on both sides, while also showing the exact problem Ritualy needed to avoid: a ticket-based model that gives hosts very little control over who shows up.
-
Airbnb
Chosen for its identity verification and host-guest trust system. Airbnb has spent years solving a similar problem, letting strangers into a very personal space. Their approach to verification and review-based trust was directly useful, even though the space here is a family celebration instead of a house.
-
Couchsurfing
Studied for its community trust model, where hosts choose who stays with them based on profiles, references and mutual vetting rather than payment. A smaller, less polished platform, but the underlying dynamic, being invited into someone’s private life by choice rather than by transaction, was exactly what Ritualy needed to borrow.
Together, these three didn’t just inform features. They confirmed that the core challenge here was trust infrastructure, not travel logistics.
05 / Survey results
The product risk wasn’t demand. It was designing something neither side would feel embarrassed to be part of.
I surveyed two separate groups: travellers interested in cultural experiences, and members of families who had hosted or attended large Indian weddings. A few findings shaped the direction early on:
- Most travellers said a paid ticket to a wedding felt uncomfortable to them personally. They still wanted the experience, but they wanted to feel chosen, not just charged
- Nearly all respondents from the hosting side said they would be open to inviting outside guests, but only if they could see who those people were beforehand and had the final say
- Both groups independently raised the same concern in different words: nobody wanted the experience to feel performative, staged or disrespectful to the actual event
06 / User personas
Two personas, representing the two sides of trust.
The host family
Preparing a wedding celebration
Proud of their traditions and open to sharing them, but cautious by default about letting unknown people into something this personal.
Pain points
- No reliable way to verify who a stranger actually is
- No way to set boundaries once someone is in
- Feeling like existing platforms treat their wedding as inventory
Goals
- Share their culture on their own terms
- Maintain full control over their guest list
- Feel confident that any outside guest understands and respects the occasion
The traveller
Travels to understand a culture, not to photograph it
Tired of experiences that feel curated for tourists rather than genuinely shared, and looking for something closer to the real thing.
Pain points
- Most authentic experiences feel packaged
- No clear way to prove their intentions are genuine before being trusted with access
Goals
- Access a real, unstaged cultural experience
- Be respectful and welcomed rather than tolerated
- Build an honest connection with the people hosting them
Both personas wanted almost the same thing, from opposite directions.
To know the other person was genuine before anything happened. That single insight became the design brief for nearly everything that followed.
07 / High-fidelity UI and screens
The four surfaces that carried the most trust-related weight.
Visually, the interface stayed warm and understated rather than flashy, since the platform’s role was to support a genuine human exchange, not perform one.
-
Identity verification flow
A guided verification process for both hosts and travellers, designed to feel like a safety step rather than a bureaucratic wall. Clear explanations at each stage answered the unspoken question every user had: why do you need this, and what happens to it?
-
Host control dashboard
A space where families could set exactly what they were comfortable sharing, from how many guests they would accept to which parts of the celebration outsiders could attend, and review traveller profiles before approving anyone.
Design decision: approval defaults to the host, never the platform. Ritualy could suggest good matches, but the final yes always belonged to the family.
-
Traveller profile and intent
Instead of a generic booking form, travellers build a short profile explaining their interest and cultural curiosity, giving hosts something real to evaluate beyond a verified name and a payment method.
-
Match and request flow
A simple, low-pressure way for travellers to request attendance at a specific celebration, and for hosts to accept, decline, or ask a clarifying question first, keeping the conversation human instead of instant and transactional.
On the live site
Trust is visible on every page.
01
The Seal of Trust
Four promises sit right below the home page hero:
- Managed journey: GPS-tracked private transit from the hotel to the ceremony
- Verified pedigree: partner families who share values of safety and hospitality
- 24/7 liaison: a personal cultural guide always one step away
- Secured payments: encryption and escrow for every transaction
02
Verification where the decision happens
Each wedding page puts the host, their rating and how long they have been a member next to three badges, and keeps the booking card in view.
- Verified host: identity confirmed by government ID
- Secure event: venue and security vetted
- Cultural guide: English support included
Booking detailThe booking card shows the price per guest, the dates and guests, and a reminder that nothing is charged yet.
03
Knowing what to expect
A day-by-day schedule lists each ceremony with its time, suggested attire and a short cultural guide, so guests arrive dressed right and understand the rituals they are part of.
Screens
Browsing, featured experiences and answers up front.
08 / Usability testing
None of the issues were really about the interface.
I ran sessions with participants representing both sides: people simulating the host experience, and others walking through the traveller journey. What I learned:
- Hosts felt reassured by the verification badge, but wanted to see why someone was verified, not just that they were
- Travellers found the intent profile step meaningful, but the first version felt more like a job application than a genuine introduction
- Both groups wanted a way to ask a small question before fully committing, which the original flow didn’t allow for at all
They were about making the system feel like it understood how much trust it was asking for.
09 / Iterative design
Three changes, each one moving further from “booking system”.
Based on testing, I made a few key changes:
- Added a short, plain-language explanation next to every verification badge, so trust felt earned and visible, not just implied
- Rewrote the traveller intent profile to feel more like a conversation starter than a form, with softer, more personal prompts
- Introduced a lightweight messaging step before approval, so hosts and travellers could ask each other something small before either side committed
Key takeaway
Not every design problem is about reducing friction. Sometimes the right amount of friction is what makes people feel safe enough to say yes in the first place.
Verification, intent profiles and a host’s final say all slow things down on purpose. Designing for genuine trust between strangers meant resisting the urge to make things faster, and focusing instead on making them feel right.
Balancing two very different kinds of caution, a family protecting something personal and a traveller hoping to be welcomed, taught me that good design here wasn’t about convincing either side. It was about giving both of them enough information to decide for themselves.