BetterBooking.ai

01 — The product problem

An AI that negotiates for you — but how much should it decide?

BetterBooking.ai is an AI assistant that negotiates Airbnb prices on a guest's behalf, built as a browser extension guests use alongside the sites they already book on. Negotiating is awkward and time-consuming for most people — the product's bet was that an AI could do the back-and-forth for you.

I joined at the concept stage, before any of that existed as a real flow, as the sole designer. The interesting design problem was never "can the AI negotiate" — it was where the AI should act on its own, and where the guest needed to stay in the loop.

Early flow mapping — translating the AI-negotiation concept into a real, step-by-step journey.

02 — The UX challenge

Guests were asked to invent a number they didn't have

The first version of the flow asked guests to type in their own target price before the AI would start negotiating. That's a reasonable-sounding requirement — but it assumes the guest already knows what a fair target price is, and most don't. Airbnb doesn't tell you what a host might realistically accept.

This framing is my synthesis of the problem, not a quote from an original research brief — it's the tension that kept showing up once we started designing around AI-assisted pricing.

03 — Initial assumption

What the first version assumed

The earliest flow treated the target price like any other form field: the guest fills it in, the AI sends it. The assumption behind that design was straightforward.

04 — Research

Testing that assumption with real users

Once the revised flow had a working prototype, I ran remote interviews to see whether the target-price assumption actually held up.

User stories and interview notes from the alpha research sessions.

No formal affinity map was built — synthesis happened directly from interview notes, and pricing uncertainty was the recurring theme.

05 — Key insights

Users didn't know what "reasonable" looked like

Research surfaced pricing uncertainty clearly. It didn't fully answer the trust question — that stayed open through the rest of the project.

06 — Design exploration

Three ways to split the decision

Before settling on a direction, I mapped out how much of the pricing decision could reasonably sit with the AI versus the guest. These were concepts I considered, not variants that were built and tested head to head.

Option C reduced the effort of Option B's automation without losing the control Option A protected — the guest still decides, but from a starting point instead of a blank field.

07 — The key product decision

AI recommends. The user decides.

08 — Final interaction

From generating a number to evaluating one

Same negotiation card, same fields — the only change is who fills in Target Price first: the guest, or the AI.

The redesign didn't remove the guest from the decision. It changed the task from generating a number to evaluating one — a lower-effort, lower-stakes way to reach the same input.

Accept / adjust / decline states for reacting to the recommendation weren't part of the shipped interaction I validated — see Section 13 for where I'd take that next.

09 — Validation

What the prototype testing actually covered

I built a high-fidelity Figma prototype and tested it before any of this was built — the browser-extension format made it hard to catch friction any other way once it shipped.

Testing confirmed the flow was legible, but didn't isolate whether the recommendation itself changed negotiation behavior — that stayed an open question.

10 — AI trust & edge cases

The questions beyond the happy path

An AI negotiating on someone's behalf raises questions that don't show up in a first-pass flow. These weren't fully designed during my engagement — they're the open questions I'd want answered before giving the AI more autonomy.

• What happens if the AI can't generate a confident recommendation?
• What if the listing has too little pricing data to go on?
• What if the host rejects the offer, or counters?
• What if the guest disagrees with the AI's number?
• What if the price changes mid-negotiation?
• How much autonomy should the AI have before it needs the guest's approval?

Framed here as open questions / next areas to validate — not as work that was completed.

11 — Design → development

Staying close through implementation

Once the interaction was validated, the designs moved to the frontend team — but handoff wasn't a Figma file and done. I stayed in follow-up meetings, reviewed builds against the design, and worked through edge cases the static screens hadn't anticipated. Most of that work was about behavior and consistency — how a component should respond in each state — more than it was about exact spacing values.

Badges, buttons, and the Target Price field — annotated directly from the shipped negotiation card for the dev handoff.

12 — Outcome

What actually shipped

13 — What I'd do next

Where I'd take this if I kept going

1. Test different levels of AI autonomy — recommend-only versus act-with-approval versus fully automatic.
2. Validate more directly whether users trust an AI-generated price, not just whether they understand it.
3. Measure negotiation completion rate, not just comprehension in a prototype.
4. Measure how in-control users actually feel, not just how in-control the flow looks.
5. Test repeat usage — does trust in the recommendation change after the first negotiation?
6. Understand whether the AI's recommendations actually improve negotiation outcomes, or just make the ask feel easier.

14 — Contributions

What this project actually asked of me