Context
Category: AI-First Product Design / Travel & Hospitality / Concept R&D
Role: Product Strategy, UX Architecture, AI Interaction Design, Prototyping
Type: Self-initiated R&D — AI-First UX practice
Live Prototype: Figma
Tools
StayOS - AI First Trip Organiser
Rebuilding Airbnb as an AI-first travel experience
StayOS is a self-initiated R&D project asking a simple question: what would Airbnb look like if it were designed today, AI-first, from the ground up?
Airbnb’s interface is a product of the search era — filters, grids, and endless scrolling. It is very good at showing you rooms. It is not designed to help you decide. StayOS replaces that model with one that reads intent in plain language, weighs trade-offs on the traveller’s behalf, and returns a small set of well-reasoned trip proposals instead of hundreds of listings.
Airbnb returns four hundred listings. StayOS returns three — and tells you why.
The Challenge
Every major booking platform pushes the cognitive load onto the traveller:
- Filter fatigue — a human need (“somewhere quiet, safe for the kids, with parking”) has to be hand-translated into a dozen checkboxes
- Choice overload — hundreds of near-identical results, ranked by a relevance nobody can see
- Invisible trade-offs — the cheaper stay is forty minutes further out and up three flights of stairs, but nothing says so until after you’ve booked
- Listing-level thinking — the platform sells rooms; the user is planning a trip
The decision itself is left entirely to the user, reverse-engineered from photos and an hour of review-scrolling.
The Objective
StayOS needed to:
- Capture intent in natural language, not filter panels
- Return fewer options — three, not three hundred
- Make the reasoning visible: why this, what you gain, what you give up
- Think in trips — stay, parking, experiences, and daily life around the property
- Keep the human in control: every AI assumption editable, every permission optional
This was not a visual refresh. It was an interaction-model change — the AI is the interface, not a chatbot bolted onto a search page.
This was not about better search. This was about better decisions.
My Role
I owned the full arc — problem framing, AI interaction model, UX architecture, and a working prototype.
Two documented phases preceded any interface work: Phase 1 defined the product vision and market thesis, Phase 2 tested it against traveller behaviour and competitive gaps. From there I designed a sixteen-screen system, shipped it as a functional deployed prototype, and rebuilt it as a wired, clickable Figma flow for testing and developer handoff.
Design Approach
Intent
Over Filters
The journey begins with a sentence, not a search bar.
Natural-language trip intent
Editable AI assumptions
Trade-off dials instead of checkboxes
Three
Not Three Hundred
Forty-one stays scanned. Three proposals returned.
Each one named for the traveller it actually suits
not ranked by an algorithm the user can’t see.
Visible
Reasoning
What you gain. What you compromise.
Confidence level on every proposal
The first 24 hours simulated before you commit
The Outcome
StayOS demonstrates that an AI-first interface succeeds by removing decisions, not by adding features — the measure is how much the traveller no longer has to do.
What was built: 16 screens covering the full journey from intent to active trip · a functional deployed prototype · a clickable Figma prototype with 85 wired interactions · two phases of product and research documentation.
What changed for the traveller: a filter panel replaced by one sentence of intent · hundreds of results reduced to three explained proposals · eight decision criteria compared side by side that a user would otherwise assemble by hand across a dozen browser tabs · trade-offs and friction surfaced before booking rather than discovered on arrival.
- A decision engine, not a search engine
- Fewer options — each one explained and defensible
- Trip-level thinking: stay, parking, daily life and risk in one view
WHAT’S NEXT ?
StayOS is a living concept. The next build phase would:
- Validate the three-proposal model with moderated testing against a filter-based baseline
- Connect live inventory and pricing APIs to pressure-test the reasoning layer
- Extend group decision-making into real-time multi-user negotiation