Rebuilding PIARY's Weekend Booking Flow from 5 Clicks to 1
Pia Machicon is a booking platform for group blind dates and matchmaking events across Japan. My task was to improve the booking flow — but after looking at the data, the real problem wasn't the flow itself. The product had no shortcut for the thing users came to do most.
View the live website ↗Project
Weekend event booking optimization
Industry
Bridal, matchmaking, ecommerce
Duration
Aug – Sep 2025
Role
Engineer x Designer
Platform
Responsive website
Problem Framing
85% of bookings were for weekend events. But finding a weekend event took 5 steps.
Looking at the booking data, I found that about 85% of all bookings were for Saturday and Sunday events. Users had a clear goal: find something to attend this weekend. But the homepage was built around a generic search form — pick a date, pick an area, then search. There was no direct path to weekend events. The users with the clearest intent were taking the longest route.
What the data showed
The existing flow problem
A repeated friction cost
Existing search flow — Before
Solution
Instead of improving the search form, I built a direct path that skipped it entirely.
My first instinct was to improve the existing search form — but I quickly ruled it out. Making the form easier to use doesn't help if users still have to use it every time. The problem wasn't how the search worked; it was that search was required at all. So I added a new section to the homepage: a dedicated view of this week's and next week's events, shown automatically without any form interaction.
01 Auto-detect the user's area
For guests, the section defaults to Tokyo (most events). For logged-in users, it pulls from their registered area. The moment the page loads, users already see relevant events — no input needed.
02 Weekend event shortcut
A new 'Events This Weekend' section on the homepage shows this week's and next week's events directly. Users reach the full event list in one tap, without touching any form.
03 Scannable card layout for mobile
Most users browse on mobile, so I prioritized browsing over inputting. Each event card shows the name, date, area, and remaining spots at a glance — easy to scan, easy to decide.
04 Design and built it myself
I handled everything from wireframes to production code (PHP + jQuery). By keeping design and development in one person, the final product matched the intended experience exactly — no lost detail in handoff.
'Go This Weekend' module — After
Technical Edge
Owning the full process — from design to code — meant nothing got lost in translation.
On this project I handled UX analysis, UI design, front-end, back-end, and post-release monitoring — all myself. When design and engineering are separate, intent gets lost between the two. By owning the full chain, every detail decided in design was implemented exactly as planned.
Scope
- Analyzed booking logs to identify the core drop-off
- Wireframed and designed the UI in Figma
- Built front-end and back-end in PHP (EC-CUBE / Laravel) and jQuery
- Monitored behavior after release and iterated
Implementation Lens
- Connected member DB and session to auto-set the default area
- Used AJAX so events load without a full page refresh
- Optimized tap count and card layout for mobile users
- No spec handoff — design decisions translated directly into code
Impact
Cutting the path to 1 step improved both conversions and the overall experience.
Effort Reduction
80%
Weekend event access went from 5 steps to 1. The repeated friction that users experienced every week was gone.
Conversion Impact
CVR ↑
Weekend event bookings increased. Shorter path to the right inventory meant more users completing a reservation.
Side effect
Support ↓
'Can't find events' support inquiries decreased. When users can find what they need on their own, support load drops too.
Learning
Ask what the real problem is before deciding what to improve.
Data tells you where to look, not what to build
When I saw the 85% figure, my first thought wasn't 'build a weekend UI' — it was 'why hasn't this been built already?' Data points you toward the right question, not directly to the answer. In this case, asking that follow-up question is what led to the right solution.
A generic UI can unintentionally disadvantage specific users
The existing search form looked fair — it treated every user the same. But in practice, the users who came most often (weekend event seekers) were the ones doing the most unnecessary work every time. Treating all users identically can mean treating the most frequent ones poorly.