Overview

Users couldn't book home swaps

I co-founded Twin City, a home swapping platform for creatives. We'd grown to 3,000+ users but investors wouldn't fund us without proof of monetisation. I discovered monetisation only worked after users completed their first swap. So I redesigned the requesting flow to unlock successful swaps in four weeks, with one engineer and no research budget.

The Old Experience

The Problem

Swappers couldn't align travel schedules

Every swap started with excitement — everyone wanted their The Holiday experience. But they’d get stuck trying to coordinate travel dates because the platform wasn't guiding them to compatible matches. Most quietly gave up. No swaps meant no revenue.

Research

The problem lay in availability not trust

I assumed trust was the blocker. Interviews proved otherwise. Users were willing to swap — they just couldn't find date-compatible matches and weren't sending enough requests.

Problem I: Users can't find date compatible matches

User Interview Insight

And how do you choose who to message?

Old UI - Choosing homes from search

I log in with a trip in mind. I want to go to Amsterdam 1–7 August,

and this person looks available in August, but when I propose my

dates they're not free, so I just pick homes I'd like to stay in

Problem II: Users didn't send enough requests

User Interview Insight

And how come you only sent three request?

Old UI - Choosing homes from search

It feels like a lot of effort. I'm composing messages from scratch, proposing dates, and if they say no, it stings. So I just don't bother.

Root Cause

The system matched on location and aesthetics, but not dates — the factor that actually made swaps happen. Availability was too vague to filter by. Requesting was too effortful to do at scale. Both left date alignment to chance.

Ideation

Availability unlocks requests

Users told us they wanted a travel calendar to express availability clearly. But that solved only half the problem.

"When I explored how users think about expressing their availability, a travel calendar emerged as the natural format. Users mapped their actual patterns — holidays, work trips, flexible windows — and the calendar structure clicked."

When we analysed the messages, we saw another pattern: users sent very few requests. Those who did felt the effort was high — composing messages from scratch, proposing dates manually. And when rejected, it stung.

So we had two connected challenges:

One: Make availability visible so users can interpret it correctly when browsing.

Two: Make requesting fast and effortless so users send more, and rejection stings less.

We explored making requests come directly from the host's profile availability — users select dates that are already confirmed, add a note, and send. No date negotiation needed. No wasted effort.

[Wireframe or visual showing: availability calendar → profile → request flow]

Then we tested this approach to see if it actually solved both problems.

Usability Testing & Iterations

Validating under constraint

We had four weeks and one engineer. We couldn't do extensive testing cycles, so we focused on validating the core hypothesis: would availability-guided requests actually stop the date negotiation loop?

We tested with six users. The answer was yes. Users could only propose dates the host had confirmed. Hosts were more likely to respond positively. Conversations moved forward instead of stalling.

But testing also revealed two small friction points we could fix quickly:

**Multiple availability windows** — Users had complex travel patterns (holidays, work trips, flexible periods). Making them add one window at a time felt laborious. We allowed up to five windows per update, so they could express their full availability in one session.

**Clearer profile language** — Users hesitated before sending requests because profile availability felt ambiguous. Changing "Available in August" to "Available 1-7 Aug" gave instant clarity and confidence.

We shipped with these refinements. The real learning came post-launch, speaking to users as they actually used the platform. That's where we discovered what truly mattered.

Developer Trade Offs

Honest about constraints

With limited budget, we couldn't optimize the new designs for mobile. So I looked at the data. The biggest mobile activity was chats — when users were communicating about swaps.

We made a conscious choice: guide users to move conversations to WhatsApp once connected instead of forcing them to stay on platform.

This went against instinct. Everyone says keep users in-platform. But we understood something mattered more: getting swaps to happen. Better to remove friction in communication than create it by forcing users into a clunky experience.

The Solution

Structuring intent before interaction

I restructured the experience so date alignment happened before any conversation. Hosts set their travel calendar. People propose dates directly from that calendar. This removed negotiation and reframed the decision from 'Can we align?' to 'Do I want this swap?'

Impact

Value first. Subscription after

The founder wanted to charge at booking. I disagreed. Users said it felt fair to charge upfront — but I noticed something deeper. Many were doing home swapping for the first time. It was new behaviour requiring real trust. A paywall at that stage would kill momentum and block the growth the business desperately needed.

After their first swap, users' mindset shifted completely. "I'm doing this all the time. This is amazing." Suddenly, the subscription felt like a no-brainer. So I implemented first swap free, monetise after. Prove value first. Ask for money second..

Final Designs

Stripe meets Vogue

I decided the UI needed a facelift — something that would make creatives feel inspired while using it. The brief I landed on was Stripe meets Conde Nast.

Adding Availability

I decided the UI needed a facelift — something that would make creatives feel inspired while using it. The brief I landed on was Stripe meets Conde Nast.

Browse & Request

Users find date-compatible matches and send confident requests in seconds.

Reflections

Assume You're Wrong

I started Twin City thinking the problem was interaction and trust. But when I actually listened to users, the real problem was something entirely different — availability. That taught me something fundamental: my assumptions carry very little weight compared to what users actually tell me. Now I start every project assuming I'm completely wrong, then let user research prove or disprove it.

Design is honest communication

Every element on a page answers a question in a user's head. An icon isn't decoration — it's communicating something. A label isn't filler — it's answering "what does this mean?" Good design removes the gap between what users need to know and what we're telling them. It's not selling. It's being clear.

Contact Me

Have a project we could
work on together?

Available for freelance projects from Q3

IY • Product Designer