Designing an app that helps hangout plans come to life
Inline books tables. But a table is the last step of a much messier process. On this project, I worked with Inline to design Pop, a social planning planning app that helps young adults make plans.
My Role
Designer
Direction, flows, visual system, and both rounds of testing
Team
2 UX Designers
Me, plus a teammate who authored the research document
Duration
6 months
Research through final prototype and handoff
Tools
Figma
FigJam, Figma Make, and Claude for prototype builds
Project Summary
PROCESS
Prototype overwhelmed users.
A V1 prototype answered coordination with intelligence. Nine usability sessions said people wanted shorter.
OUTCOME
A final prototype that consolodates a planning process
We created something simple that can help users easily create and coordinate events.
PROBLEM
Plans die before they become bookings
Likelihood-to-use moved from 5–6 to 8–9 out of 10, and the tone finally read as casual rather than corporate
01
Goal
Helping people get together before they book a table
Getting together often starts with a simple thought: “We should hang out.” At that point, the date, place, and even who’s joining may still be undecided. Turning that idea into a plan means going back and forth across group chats, comparing availability, suggesting places, and checking who’s interested or confirmed.
For Inline, this presented an opportunity to support the moments that lead to a restaurant reservation. Through an exploratory product initiative, inline wanted to better understand young adults’ social circles: who they make plans with, how they decide what to do, and what helps a gathering come together.
The aim was to explore whether making group planning easier could encourage more in-person gatherings and create new opportunities for restaurant discovery and reservations. I partnered with another UX design intern to explore a social planning app that helps groups shape plans together, even before the details are settled. I led the design and prototyping, while my partner focused on user interviews and documentation.
PRODUCT GOAL
Help people coordinate and execute hangout plans. Coordinate a date & time, choose a place, & see who’s joining, with less back-and-forth.
03
Research Insights
“Maybe” is not indecision, but rather missing information.
A heuristic evaluation and secondary competitor research with six competitors gave us an understanding of what the market had, lacked, and needed.
User interviews with our target demographic and stakeholder interviews help us find balance and commonalities between business needs and user needs.
User interviews and synthesis produced four concrete insights for me to design a solution for. One finding has had inverted an assumption I had while tackling this project.
​
I had assumed a Maybe was a polite no. In many instances, a maybe is a yes waiting on a fact the invitation did not give the guest: how far away it is, how much it costs, who else is going, or whether their Saturday is still open.
Rather than chasing people for firmer answer, we should design to give them the missing facts.
THE PROBLEM
THE NEED
A maybe reflects uncertainty, not a lack of interest
REDUCE FRICTION
Feasibility comes first, final answers come later
FLEXIBLE COMMITMENT
Who else is going drives whether people go
SOCIAL CONFIDENCE
Plans die in the gap between asking and answering
STREAMLINE COMMUNICATION
04
Process
Rapid-prototyping with AI for feature prioritization
First, I used Claude AI and Figma Make to create a prototype that combines our ideal features, based on low fidelity wireframes and user flows I have mapped out. For the prototype, we noticed that group planning fails because information is scattered and stale, then the product should watch the plan and keep everyone current. I mapped out a list of features that the current prototype should have. And with the help of Claude AI and Figma Make, confidence levels, auto follow-ups, a momentum indicator, venue suggestions, day-of coordination, soft nudges, and frictionless replanning.​
​
From there, we narrowed down what features or user slow should and shouldn't be included in the final product.
ROUND 1
Each participant ran both host and guest flows against a task list and thought aloud. Four of nine finished the core task unaided.
01
The review and decision phase was the worst moment in the product
RSVP confidence levels and calendar sync were buried there, so several testers finished the flow without ever discovering them. The grouping read as arbitrary.
02
Advanced settings were where features went unnoticed.
RSVP confidence levels and calendar sync were buried there, so several testers finished the flow without ever discovering them. The grouping read as arbitrary.
03
Event creation felt long and overwhelming.
Participants took a long time to work out what each step wanted from them, and said the volume of information was too much for deciding on a Friday dinner.
V1 BUILD
01 — Participants felt that the process of inputting poll options is not intuitive.
02 — The biggest friction points occur during the review and decision phase, as the tabs confused and overwhelmed users.
03 — Users felt like they were filling out a form, rather than dishing out a fun event invite to friends.
METHOD NOTE
After mapping out features and low fidelity wireframes, we experimented Figma Make and Claude AI to create functional, high-fidelity prototypes in a couple of days. Instead of testing static mockups, we put real, clickable flows in front of users almost immediately, which is how we fit two full rounds of research-backed iteration into the timeline instead of one.
05
Solution
Make an event in a few taps with or without
a plan.
From a user's perspective, we had to start thinking about how to make events clear, easy, and most of all fun.
So we cut and rebuilt. I restructured the RSVP page down to only what a guest needs to decide in the moment (event name, date, location, and the RSVP action) and pushed everything else (polls, availability, extra details) into secondary screens that only surface when they're relevant.
We consolidated event creation from a string of single-field screens into a few grouped ones, which shortened the flow without cramming it.
01
Make your event personal
Customize the color, typography, and theme of the event to your liking.
03
Draw your availability
A start and an end is all the host owes the group. Guests fill the rest in a drag-select grid.
02
Coordinate in one tap
Don't know where or when everyone's available? Create poll options, or collect availability from guests in one tap.
04
Share an invite in seconds
Send out an invite link, available to everyone without an account. RSVPs land back in the host's feed.
06
Results
Consolidating the features doubled the
completion rate
For the final round, ten different testers used the old and new prototypes back-to-back, sharing their screens as they worked through the same simple tasks on each: create an event as a host, then respond to one as a guest.
Users independently described the old version as text-heavy and overwhelming, calling it better suited to higher-stakes, formal events like weddings than a casual hangout. The new version, by contrast, read as casual, fun, and immediately recognizable as something built for Gen Z.
They also singled out the built-in chat as a real improvement over juggling separate apps to coordinate. The numbers backed up what they said: rated likelihood-to-use jumped from 4 out of 10 on the old prototype to 9 out of 10 on the new one.
9 of 10
finished unaided, up from 4 of 10
1:05
Median time to create event, down from 4:12
4
key screens, down from 10
"I could tell in ten seconds whether an event was actually happening or still up in the air."
- Participant 4, Round 2
07
What I learned
Key takeaways from this project
WHAT I LEARNED
A correct insight does not guarantee a correct feature. Some features weren't effective because we treated uncertainty as information to display rather than a problem to design around.
​
Good UX isn’t about solving everything at once. We tried to solve every pain point with a feature, but this introduced unnecessary complexity.​
​
​
WHAT I WOULD DO NEXT
Test V2 at round 1 scale. Two comparative sessions confirm a direction. Comparative testing with competitors would be my next step..​​
​
Funnel into Inline's reservation system. Right now, the apps function independently. However, there is an opportunity for us to funnel events planned at restaurant into Inline's reservation systems.
​
​
View my other work
Let's build something awesome :)