Introduction
Joyin is a mobile application designed to discover local events and quickly form a community around them
MY role
Product Designer & Researcher
Main goals
make it easy to find relevant events happening nearby
help people build real connections through small groups and activities
simplify event creation and management for organizers
Methods
User Interviews / User Personas / JTBS Customer Journey Mapping / Competitive Analysis / Wireframing
User Interviews
Users destroyed my original idea — and showed me what really matters
6 interviews that changed the direction of the product
Challenge — The initial focus was wrong
The product started with an assumption: people are looking for big events — concerts, theater, exhibitions.
Formats:
yoga in the yard
live music in a bar
stand-up in a cafe
mini-workshops
cozy meetings based on interests
The value is not in scale, but in emotions and contact.
I have a child and sometimes it's hard to find an event where you can spend an evening with your family, and I would like personalized selections based on my experience.
Communication is very important to me, people from different fields can help somehow, it's interesting to chat
For me everything depends on my mood — if I’m in the right mindset, I can go out. But I’ll only go if someone invites me. I never go alone to events like these.
Communication is very important during a workshop. They only ask for your name, but the workshop itself isn’t engaging.
It would be very useful for me to have a map while traveling — if I have a free hour, I could quickly check what’s happening nearby, like an exhibition.
Since everything revolves around Instagram, it would be convenient if after posting a photo there you could also upload it into the event automatically.
It's very hard to find a community, so I want to create one myself.
When you're in your own neighborhood you don’t always know where else you can go, or what’s available in another part of the city
after
To create the right product, you need to understand who it exists for and what work it does
After the interview, it became obvious: the product works for two different segments at once with different scenarios, motivations and pain points.
In my product, these are two key segments:
people who are looking for events and want to diversify their leisure time
What needs to be instant in the app (JTBD → features)
Find nearby events in 1 tap
See the vibe, people & format instantly
Join the event in 1 click
Get logistic clarity (where/when/how long)
Save / share in 1 tap
Access ticket instantly
Rate & add photo after the event
organizers who hold intimate events and work with the community
What needs to be instant in the app (JTBD → features)
Create the event in under 2 minutes
Duplicate or plan recurring events
Manage participants easily
Accept prepayments
Update event details instantly
Share event to IG/Telegram
Access ready locations
Competitive Analysis from the Inside Out
Minimum steps to action
Maximum clarity in the interface
I mapped all key scenarios, prioritized screens, and built an architecture focused on one principle: remove friction, reveal what's essential, and make the main actions instant.
Goal
Structure the core user flows and define a product logic that truly matches the needs of two very different audiences — event participants and event organizers.
Impact
This foundation made it possible to move into wireframes with full clarity on:
what users need to see first
which actions must happen in one tap
and how to support the fastest paths:
discover → register → attend for participants
and create → publish → manage for organizers.
mini-workshops
cozy meetings based on interests
Site map
To build a better product, you first need to understand where competitors fail — and where they actually deliver
To uncover where the market truly breaks, I went far beyond screenshots and flow comparisons.
I walked through the full user journey inside 5 competing apps, signed up for real events as an actual participant, and dissected their UX from the inside.
This showed not what competitors claim to do — but how their products actually feel in action.
What became immediately clear
browsing an event
understanding its details
registering in one seamless step
Wireframes
After the first prototype, it became clear: the initial architecture couldn’t handle real user behavior
Flows were breaking, roles were blending, and navigation was losing people.
This was the moment when the solution had to be systemic — not cosmetic → Architecture V2.
Challenge
The event-creation flow didn’t work for most users
Most users attend events — they don’t create them.
So the navigation structure must be optimized for discovery and participation, not creation.
Event creation should stay accessible, but never dominate the experience.
Impact
Clear separation between discovering events and managing personal activity.
Lower cognitive load — primary actions stay visible, secondary ones don’t compete for attention.
A scalable, logical foundation that supports both attendees and organizers without mixing their flows.
