Rebuilding YukStay's booking flow and homepage

The problem

Two symptoms, one root.

Booking a visit meant a conversation with ops. A visitor could only request a visit. Behind the scenes, ops had to chat the user to agree a date and time, then find an agent free at that time. Rescheduling was worse: agents handled it directly, so ops could not track it, which made booking new visits harder still. With one agent handling 5 to 10 users a day, every visit also had to leave room for travel time and for the previous visit running over. That was the operational hazard.

Discovery did not exist. Analytics showed users dropping out when choosing a location from a dropdown, and agents told us most visitors only knew about YukStay's coliving product, not the wider unit-rent offering, which existed only as a filter buried in apartment browsing.

Mini interviews with the ops team and the agent team confirmed the shape of both: users could not express "near me" in the old location search and worked around it by booking any unit and then asking the agent whether anything closer existed; reschedules tracked by agents meant agent time was hard to plan; and late arrivals caused by overrunning visits made the wait worse for the next tenant.

Constraints

• Design was two people, with no separate research function, so discovery was interviews plus desk research run by the same people who designed the answer.
• Testing capacity was thin. For the booking work we tested internally with the ops team and ran UAT with stakeholders.
• Agents would not maintain a calendar. This shaped the whole solution: anything that depended on agents keeping availability up to date was already known to fail. Agents spent their days on a motorbike in Jakarta traffic chasing the next appointment.
• Existing habits had to survive the redesign. The location search was working well enough that moving it would have cost more in relearning than it gained in tidiness.

What I did

Booking experience. We framed it as one question: how do we make scheduling a visit easier for both the user and the agent. We generated three options: an agent calendar, a web page showing agent schedules, or letting users request a specific time.

We chose the third. The calendar options depended on agents keeping availability updated, which we knew from experience was unreliable. Asking the user to pick a time needed almost no change to how ops worked, and it addressed both sides' problem.

The design mimicked booking a seat in a movie app. It was not the simplest possible experience, but seeing which slots were taken and which were free was clearly what users valued. Each booking assigned 1.5 hours of an agent's time, covering travel and the visit overrunning. A WhatsApp reminder reduced no-shows, and we later put rescheduling inside that reminder, so an agent would no longer travel half an hour only to find the client wanted to move the visit. That worked because the booking system was integrated with the agent app, which showed each agent their schedule in real time.

We tested with ops internally and ran UAT with stakeholders, then added a short post-booking feedback prompt, and made the booking function float instead of sitting statically so it stayed reachable on a long page.

Homepage revamp. We benchmarked similar products (Redfin, Trulia, 99.co and Airbnb) and applied what they did well. The page got cleaner, with more deliberate white space so information was easier to scan, and we kept the location search where users already expected it. We added a product section so YukStay's offering could be found and filtered rather than discovered by accident.

We also experimented with the user's cache. If someone had already searched, they no longer got the large jumbotron, on the assumption that they already knew what YukStay was. That space went to products, promotions and recommendations instead.

Key decisions and trade-offs

We rejected the agent calendar. A live calendar would have solved scheduling more thoroughly than a time-request, but it depended on behaviour we had already seen fail. A smaller solution that survived contact with agents was worth more than a better one that did not.

We kept the location search where it was. The tidier redesign would have rebuilt the top of the page around a new search experience. Keeping it cost us visual ambition and bought continuity for people who already knew the site.

We tested internally instead of with users, on the booking work. Internal UT with ops plus stakeholder UAT was what time and resources allowed. It caught functional problems; it would not have caught comprehension problems.

The homepage stayed guest-first. Visitors still arrive without an account or preferences, so the homepage still had to work for someone who has never seen it. We limited personalisation to the jumbotron cache rather than rebuilding the page around returning visitors.

Outcome

The homepage work moved the schedule visit rate from single-digit into double-digit percent, which was the step we had identified as the leaking one.

For the booking work there is no comparable number, so I will report what changed in the process instead: users could see free times and request one, agents saw their schedule in real time, and rescheduling could happen from the reminder. That removed the ops-side back-and-forth the project started from.

What I'd do differently

I merged two projects into one narrative because they came from one method (interview ops and agents, then benchmark), but they ran as separate work, and the booking experience paid for it. It was the harder problem, with the more expensive failure mode (an agent's wasted morning), and it got the weaker test. Sequencing them deliberately would have saved the internal-only testing for the homepage, where the risk was cosmetic, and put the booking flow in front of real users first.

On the homepage, I should have set a counter-metric before shipping the jumbotron change. The change worked like this: if the browser showed that the visitor had searched before, we hid the big introduction banner and showed products instead. The assumption was that a returning searcher already knew YukStay. What I did not check was a first-time visitor on a shared computer, where the cache may belong to someone else — so a genuinely new person could be treated as a regular and never see the introduction. What the cache told us was what that browser had done, not who was sitting in front of it.

The benchmark list is the part I am least sure about. Redfin, Trulia, 99.co and Airbnb are large, mature products, and we borrowed their patterns faster than we validated them against behaviour on our own site. Some were clearly right. I could not now say which earned their place and which just looked credible in a deck.