/Market Gap Overview
What if short-term rentals could create the same guest experience as legacy hotel chains the moment guests turn on the TV?
Hotels have used TVs to create curated guest experiences for years. But that required expensive hardware and legacy software built for large operators. Short-term rental hosts had the same TV in every unit and no way to use it.
/Solution
WelcomeScreen: A guest experience platform that gives short-term rental hosts control over what guests see on TV and mobile, managed from a single desktop portal.
Manage TV, guidebook, and guest experience from one portal
Personalized TV experience guests see the moment they arrive
Guest-facing mobile guidebook with AI-powered welcome
/Initial Product Market Fit
A proven market demand in the Facebook short-term rental community.
Before any formal research began, a single Facebook post in a short-term rental group revealed something no one had built yet.
The question was never whether people wanted this. The research that followed was about what it needed to deliver, for hosts managing multiple properties and for guests arriving with no context and no instructions.
/User research
Understanding what hosts needed, and the moments guests felt special.
We started with hosts. Since we knew there were two sides to the product, we wanted to focus on and optimize for the buyer first. Cold calls, DMs, and emails with property managers surfaced what they needed and wanted.
Two of those needs, personalization and promotional content, meant the host placing something directly into the guest's experience. So we asked guests to walk us through what made a stay feel personal versus generic, and how they felt about hotel TVs.
The product had to do two things at once: let hosts personalize and promote at scale, while making sure that personalization still felt like a human touch to the guest, not something automated.
/Key Challenges
The core design challenges behind WelcomeScreen
With the user needs and perspective understood, we looked at the key constraints in building the product. There were structural constraints that shaped how we could deliver on what we'd learned. While there were several challenges in creating WelcomeScreen, three core design challenges stood out.
Different operating system across TV platforms
Needed to work for 1 to 500 properties
Each one carried its own design problem. A single interface had to behave consistently across operating systems with different constraints. A single screen had to feel just as simple at 500 properties as it did at 1. And the experience had to work for a wide range of end consumers.
/Design Principal
What We Committed To
The users told us what mattered. The constraints told us we couldn't afford to ignore it. Together they gave us four principles we held across every surface.
Accessible by default
Every screen works for any guest regardless of language, age, or technical comfort. Accessibility is not a feature we add at the end.
Learnable without instructions
Property managers vary in technical ability. The product has to be intuitive enough that no one needs a manual to get started.
Hierarchy over everything
The most important thing is always the most visible thing. Nothing on screen competes for attention equally.
Consistent across every surface
TV, web, and mobile follow the same patterns and components. Users learn the system once and it works everywhere.
/System Flow
Mapping the Flow Before Designing a Single Screen.
Before designing any screens, I mapped what the flow needed to be, then went back and forth with our CTO until we landed on an approach that made sense for both sides. Setup stayed simple by grouping core reservation data from the PMS and content management together in the portal. That kept everything on the guest facing side, TV and mobile, simple and predictable.
/Design System
Building the design system for a multi-surface product.
The design system was built knowing it had to work across three surfaces from day one. A large portion of it was shaped in collaboration with our CTO, and the direction we agreed on early was to keep the foundation as simple as possible, because we both knew it would evolve.
The typeface is Satoshi Variable, paired with a unified color scale, spacing system, and rounding rules. Web and mobile follow the foundation closely. TV required its own typography and spacing scale to work at distance, so we adapted those values without breaking the system underneath.
The foundation was fully tokenized and labeled with intent, so engineers always knew what a token was for. Semantics were named by use case, keeping handoff fluid as the product grew. Component-level tokens were created by asking: if I need to change this value, do I want it to affect only this component, or every place this semantic concept appears? Only this component meant a new token; everywhere meant referencing the semantic token directly, keeping the system predictable rather than over-tokenized.
Primitives hold the raw value. They exist only to be referenced, never applied directly. Semantics carry intent. Naming them by use case rather than appearance meant engineers always knew what a token was for, not just what it looked like. Component tokens inherit that intent, scoped to a single component. They existed only where a real constraint, not convenience, required a value to diverge.
The property card shows this in practice, built entirely from semantic and component tokens, with optional elements controlled through toggles rather than separate builds.
Each component exposes only what needs to vary. The Card component uses toggles to show or hide optional content, like an image or action buttons, rather than building separate versions for every combination.
/Designing for AI
As competitors moved toward AI, we looked at where it would matter most for our users
As the product matured, we became increasingly aware that competitors were beginning to incorporate AI into their offerings. Rather than adding AI for its own sake, we looked at where it could make the biggest impact for our users in the shortest amount of time. Recommendations were the answer. It was the highest friction task hosts faced, it was entirely location dependent, and it was something AI could do better and faster than any host manually could.
AI generated recommendations at scale
Hosts managing multiple properties don't have time to manually research local recommendations for each one. With one click, the system generates property-specific suggestions based on the property's location. Hosts review, curate, and publish. Guests see the result on TV and mobile.
AI Concierge
The AI Concierge is live inside the mobile guidebook, guests can ask questions about the property and get answers pulled directly from the host's content. We've since expanded it with local area awareness and photo recognition, with direct host escalation for issues that need a human response currently rolling out.
/Outcome
Trusted by property managers across 35 countries
WelcomeScreen is live in 3,500+ properties across 35 countries. I owned design across 7 core features: the desktop portal, TV, mobile guidebook, AI recommendations, storefront, analytics dashboard, and interactive TV layouts, along with several others that never shipped due to competing priorities between host and guest needs.
One feature that shipped and was later pulled back was the analytics dashboard. Surfacing usage metrics to property managers seemed valuable on paper, but once live, it worked against the core business: showing hosts exactly when their property wasn't being used risked undermining trust in the product rather than building it. We made the call to pull it rather than let a metric quietly damage retention.
/Reflection