Closing bookings quicker with a smart inbox, Boutique 2023

As a tag-team of two, we created and interactive inbox for Boutique, a platform with hand-picked holidays homes. The selective property selection means homeowners value personal connection with their potential guests. The inbox was designed to facilitate both direct communication and semi-automated booking management, as bookings are often discussed first before confirmation.

Disclaimer: Buckle up, this one is a bit of a marathon read – it was one of the most complex features I've ever worked on. I stuck to the most interesting bits, but it could easily be a novel, if I tried to be comprehensive.  Get comfy and enjoy the journey!

Non-linear complexity

With multiple alternative outcomes, including cancellations or request expirations, we needed to implement over 15 different paths to automate the booking process, enabling flexibility, while also guarding the best outcome paths.

Stuck in the past

The new inbox was part of a larger redesign – that means there was an existing version of the tool.  It was helpful to highlight painpoints (and there were many) but we also suspected we might get trapped by tradition and expectations to make it the same, just better.

Busy hosts

Many of our homeowners are busy professionals, who often don't rent their homes full time – we needed to make it easy for them to stay engaged and responsive. 

Time

Any project rarely runs without a pressing timeframe, but for us it meant operating with little room for errors or testing for the first iteration – we needed to get it right. No pressure.

Since the Inbox was part of a larger site redesign, we had the previous iteration of the platform to learn from, but also to match up to. Both users and the internal team were used to some outdated patterns, that we wanted to improve on. That bias was part of our challenge to untagle – starting with a flow helped us get back to  what and why, instead of rushing to how.

Remember how I said we needed to get it right on the first try? Well spoiler alert, we didn't. Or rather, we pivoted, to make sure we do, when we decide to implement. Amongst other things, we tripped over having  the old platform reference – some concepts were hard for the team to let go off, like moderators messages visible only to one side (yikes).

Short term pain, for long term gain – confusing features, no matter how familiar, had to be overhauled. Analyzing what problems they tried to solve in the first place, kickstarted our rethinking process. We were onto something with the idea of inline actions, but we needed to find a smarter way to:  keep the messaging  history consistent for both sides and not multiply CTAs (and figure out everything else in the meantime)

Flipped it and reversed it

We knew we had to create more consistent patterns and simplify, both for experience clarity and implementation's sake. A few design brainstorms later, with a mantra of "you can't make an omelette without breaking a few eggs", we landed on how we want to achieve it.

We standardized the actions, to follow the same patterns and limited them to a short support message and sticky buttons

Available actions were private, but after they were documented as callouts, visible to both sides to keep the chat history consistent for both sides.

Only actions that were vital to the golden path were handled inline, everything else stayed in the side panel – this way users were gently guided to not make too many changes to bookings or cancel too hastily.

Want to see what happens right before the booking request? I also worked on the checkout redesign at Boutique: