Rebuilding YukStay's booking flow and homepage

Context

YukStay is a property technology company focused on co-living and on empowering its offline agents. The website was how the company generated leads, and by the time I joined it already worked — a visitor could schedule a unit visit on the web.

The functionality was not the problem. It was that the website did not know anything about the business running behind it.

I was a UI/UX designer here, in a team of 2.

The problem

Two symptoms, one root.

Scheduling was a conversation, not a feature. 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 account for travel time and for the visit before it overrunning. 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 — and generated three options: an agent calendar, showing agent schedules on the website, 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 short feedback after a booking, 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 did not build the agent calendar, even though it was the most complete answer. A live calendar would have solved scheduling more thoroughly than a time-request. We rejected it because 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 did not move the location search. 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.

We did not change the guest-first model on the homepage. 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 unit-page view rate from single-digit into double-digit percent — the step we had identified as the leaking one, since a unit page is what a visit gets booked from.

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 would have found a counter-metric before shipping the jumbotron cache change. Hiding the jumbotron from returning searchers assumed they already knew YukStay. What I did not check is what a brand-new visitor on a shared device would see — cache is not a reliable statement about who is looking at the page.

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.