I-Y
Work
About
Contact
Twin City
Redesigning a Core Flow To
Unlock Users Goals & Revenue
Overview
Twin City is a home swapping platform for creatives in major cities. They recently launched an MVP and gained exciting early traction, 3000+ users and press in Conde Nast and Elle, but they faced a common early marketplace problem, they had yet to monetise. My job was to redesign the core requesting flow and unlock their first revenue stream in four weeks, with one engineer and no research budget.
Role
Product Designer
Timeline
4 Weeks (Q3 2025)
Impact
Monetised the platform in four weeks
The Old Experience
Message → 2. Compose → 3. Propose dates → 4. Back and forth → 5. Drop off furstrated
The Problem
Every swap started with excitement, they wanted their The Holiday Movie experience but users got stuck when they tried to coordinate travel dates Finding a match was rare and most users quietly gave up.
The Solution
Request from host's travel calendar → 2. Accept → 3. Book Swap
I restructured the flow so date alignment happened before conversation.
To do this, hosts need a travel calendar. People could then propose dates from the calendar. This removed the date negotiation and reframed the decision: "Can we make this work?" → “Do I want this swap?”
The Impact
The founder initially wanted to charge at the point of booking. I pushed back and implemented a first swap free model, even though users said paying upfront felt fair.
A paywall at that stage would have blocked bookings. Home swapping is a new behaviour that requires a leap of trust and many users felt apprehensive. After completing their first swap, however, they didn’t look back. For an early-stage marketplace, prioritising growth first was essential to solving supply and demand challenges.
Requests Sent
Research
This Problem Ran Deeper Than The Conversation
The Starting Point
Conversations were breaking down int into back and forth date suggestions → most swaps never materialised
I love your home! Want to swap July 10 -15?
Hii. I can't then but am free July 18 - 24,
Does that work?
Ahh I'm at a wedding then,
how about Aug 1 - 6?
I need to be home then :( September?
Seen
My Assumptions
This has to be a trust, matching or interaction problem
The Insight That Changed My Thinking
People only came when planning a trip - a short, high-intent window. Okay so what we're matching is this not general home swap partners.
During that window, they messaged people based on availability but kept hitting the same issue:
"“They said August… but none of the August dates I suggested worked.”
What I Realised
What I realised I was focused on fixing the conversation.
But the failure started before it.
Availability was how users expressed intent → but it was too broad to be useful as requests were specific.
Availability was vague → Most conversations started misaligned
Root Cause
Users couldn’t find overlap.
Not because of trust but because the system made intent inaccurate that caused weak matching.
Design Insight
Not a messaging problem
A misaligned availability system.
Shift in Design Direction
To fix the request flow, I had to design for both:
how users express availability
how they propose swaps
How might we make availability accurate enough
that users only propose dates that can actually work?
Ideation
Two Approaches
I explored two different ways to simplify how users send requests. A pop-up flow felt right for automating the proposals, but the bigger challenge was reducing the back and forth while giving them a clear, confident way to interact.
Exploration 1: Dates + Message
Users pick any dates and add a note.
Conclusion
The core problem remained - people naturally chose dates that didn't match the host's availability, so back and forth still persisted and momentum stalled.
Exploration 2: Availability Guided Request
Users only select dates the host is actually free.
Conclusion
Swap became more likely to happen because:
Dates always align
Users feel confident sending requests
Hosts respond more meaningfully
Usability Testing & Iterations
The redesign landed well. People told use the new experience felt 'so much clearer' and they were excited to use it. However, testing surfaced a few issues that were still holding the flow back from being fully intuitive.
Multiple Availability Slots
Before
+ Efficiency
After
Initially, users could only add one travel window at a time. Testing showed most had multiple possible dates they wanted to add. Repeating this process multiple times added friction and risked input fatigue. We updated the calendar to allow up to five slots per update, increasing the output of users availability on the platform.
Request Message Guidance
Before
+ Guidance
+ Optional
After
Users hestiated and mentioned writing the notes was a bit awkward. I added placeholder copy and made them optional to reduce friction and boost confidence.
Developer Trade Offs
Balancing Speed, Accuracy & Experience
I checked in with the developer early and often, to scope technical builds and ensure I made the most out of his limited time.
The Clunky Calendar
Not “Airbnb-style,” but accurate and reliable.
Trade-off: full redesign would delay launch.
Outcome: Users could still set availability correctly
Mobile Optimisation
Fully responsive flows weren’t feasible due to backend complexity of calendar.
Trade-off: prioritised desktop-first, while messaging stayed mobile-friendly.
Outcome: 75% of users on laptops unaffected; mobile users could still communicate quickly and coordinate swaps.
The Final Design
Availability and requesting were previously disconnected making swaps unlikely.
I redesigned them as a single system to match people whose travel calendars aligned. Design principle → I used was structure intent before interaction.
Adding Availability
Users define specific dates through a travel calendar. This communicates to others when they can swap and replaced vague signals like 'I'm available in August' with clarity and accuracy. helping the system move from matching interest to intent.
Requesting Flow
Requests start from the host's availability they set. Users select directly dates from the calendar before sending a request. By aligning dates first, conversations shifted from back and forth coordination to decision making, help people reliably find swaps.
Reflections & What's Ahead
Prototype Faster: Getting solutions in users’ hands sooner would have revealed friction earlier.
Collaborate More: Partnering with engineers and mentors from the start accelerates iteration.
Keep Users Engaged: Explore nudges, highlights, and reminders to increase return visits.
Recommendation Features: Curated swaps to help users find compatible partners effortlessly.
Contact Me
Have A Project You Want To Work On Together?
Reach out. I'm currently available for freelance projects.
© 2026 Isaac Young
Read CV