Protected
Futurestay case study.
Enter the password to view.
That's not it. Try again.
Use ↑ ↓ or scroll
Portfolio deep dive · Futurestay
Who is onboarding for?
How one persona question turned a broken signup flow into the business's best growth lever.
The ask
“Make our onboarding better.”
That was the brief. Onboarding was the worst part of the funnel, and everyone felt it. The obvious move is to accept the ticket: polish the flow, cut a few steps, ship.
I didn't do that. Before touching a single screen, I wanted to understand the users and the business behind the flow.
What I did instead
I started with the business, not the buttons.
I sat down with the team and asked about the business: the goals, the economics, who they were really trying to win. The most useful thing to come out of it wasn't a UI note. It was two people they already had names for.
Good onboarding design is a targeting problem before it's a flow problem. You can't smooth a path until you know whose path it is.
Meet the two personas
Janet and Bill.
Janet
Brand-new host
- Just bought her first property
- Hasn't even launched on Airbnb
- Doesn't know how to use a calendar or set rates
- Needs to get on Airbnb far more than she needs a direct-booking site
Bill
Established host (our real segment)
- Represents hosts with under 10 properties
- Already live and operating on Airbnb
- Knows the domain: rates, calendars, listings
- Wants to add direct booking to an existing business
The insight
The team was designing for Janet. Janet was a trap.
- Serving a total novice means building a product that can do or teach everything. A brutal lift for a young company.
- Bill needs far less hand-holding. And if we don't chase enterprise, he doesn't need the sophisticated features pro hosts expect either.
- That's the sweet spot: enough product to delight Bill, without the bottomless cost of raising Janet from zero.
I wasn't cutting Janet, just switching focus. We'd come back to her once the product was mature enough to serve her well.
Why it mattered to the business
Bill isn't just easier. He's worth more.
We charge per property. Janet launches one, eventually. Bill can launch two or three on day one. One Bill acquisition is worth multiples of a Janet, at a fraction of the support cost.
Janet
1
property, someday · high support cost
Bill
2–3
properties, day one · low support cost
So I narrowed Bill down. Not just "established host," but a sharp, tangible ICP for where the business actually was, so every design decision had a concrete person to answer to.
What Bill actually needed
So I went and talked to him.
I interviewed 6–7 Bill-type hosts to get past assumptions and into real behavior. Three needs came up again and again:
- Direct booking, to diversify. He wanted income that didn't depend entirely on the OTAs.
- Payments, made dead simple. He didn't want to figure out how to take credit-card payments himself.
- Zero added operational friction. He already ran lean. A new channel couldn't create new work, or it wasn't worth it.
That last one shaped everything: adding a channel had to reduce effort, not add it.
What they'd built
A flow built only for Janet, and it made you pay blind.
▶ Open the prototype - A long, rigid flow. Every step forced, no skipping.
- At the end: a tiny preview, then a wall asking for a credit card.
- Users paid before ever seeing the real app.
- Built entirely around Janet's cold start. Nothing for Bill.
My redesign · the concept
Import from Airbnb: Bill's whole business, in seconds.
Bill's data already exists on Airbnb. So instead of making him re-enter it, I designed a flow that pulls it in (listings, rates, calendars) and drops him straight into the real product, populated with his own properties. He sees the value before he pays.
▶ Open the prototype The prototype I pitched. Click it to walk the real flow. Time-to-value went from a long slog to a few taps.
Three years later · live demo
We shipped it, and never stopped refining it.
That concept went live. Three years of real users, data, and iteration later, it's grown into something more complete. Let me walk you through the live product.
▶ Open the live product The hard part
Getting everyone to stop over-indexing on Janet.
The team had a lot of emotional energy invested in Janet. She's the sympathetic underdog. I didn't win the argument by killing her. I reframed it: we can make it easy for Janet and Bill, but what they'd built only served Janet, badly.
The import flow is genuinely better for everyone. That's how you move a team off a cherished idea. Not by taking something away, but by showing a version where nobody loses.
How I think about it
The best design decisions happen before the first screen.
They asked me to fix a flow. The real design work was deciding who it was for. Once Bill was clear, every screen had a concrete person to design toward, and the craft got sharper because of it.