WELCOMESCREEN

WELCOMESCREEN

Designing a two-sided platform across web, mobile, and TV, where operators shape the first thing every guest sees.

Designing a two-sided platform across web, mobile, and TV, where operators shape the first thing every guest sees.

Role

Founding Product Designer

Collaboration

CEO,

CTO

4 Engineers

2 Designers (Second designer joined Jan 2026)

Duration

May 2024 - Current

Scale

4,500+ properties

1M+ guest Interactions annually

/Market Gap Overview

/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

/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

Manage TV, guidebook, and guest experience from one portal

Guest-facing mobile guidebook with AI-powered welcome

Guest-facing mobile guidebook with AI-powered welcome

Personalized TV experience guests see the moment they arrive

Personalized TV experience guests see the moment they arrive

/Signal

/Signal

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

/User research

What hosts asked for, and what guests could actually feel

I started with hosts. Two-sided product, so I optimized for the buyer first, and asked all of them the same hypothetical.

Recurring Host Needs

60+ property operators · cold calls, DMs and email

If something like this existed in your property, what would you want it to do?

Provide personalization at scale

Difficult to keep up past four properties

Difficult to keep up past four properties

Creating a branded experience

Wanted to feel like a brand, not just another Airbnb

Wanted to feel like a brand, not just another Airbnb

A channel to promote their offerings

Late checkout and add-ons, no way to reach guests in-unit

Late checkout and add-ons, no way to reach guests in-unit

Fewer repetitive questions

Wifi, parking, trash day, answered by hand every stay

Wifi, parking, trash day, answered by hand every stay

Two of these four put host content directly in front of a guest. Personalization and promotion both depend on a guest noticing while branding and repeat questions are operational, so we went to the guest side to focus on that.

Guest Perspective

40+ friends, families, strangers · In person interview

When was the last time a stay felt special at a hotel or Airbnb and why?

Do you often ask recommendations or take recommendations from hotel concierge or promotions?

What made a stay feel special

A small gesture the manager didn’t have to make

Concierge recommendations

Booked the experiences, acted on hotel promotions

Booked the experiences, acted on hotel promotions

Guests remembered effort someone chose to make. Hosts needed it to work across every property. That gap shaped most of the decisions that followed.

/Key Challenges

/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.

Challenge 01:

Different operating system across TV platforms

Different operating system across TV platforms

Solution

One interface built on a shared design system that respects the tightest constraints of every platform, so it runs reliably across all platforms.

One interface built on a shared design system that respects the tightest constraints of every platform, so it runs reliably across all platforms.

Tradeoff:

We give up platform-specific polish, richer remote interactions, and native integrations, for one consistent experience across every OS.

We give up platform-specific polish, richer remote interactions, and native integrations, for one consistent experience across every OS.

Challenge 02:

Needed to work for 1 to 500 properties

Needed to work for 1 to 500 properties

Solution

I design for the largest operators first, then let that scale down. Property cards collapse into lists as volume grows, and PMS syncing works the same at 1 property or 500.

Tradeoff:

A small operator inherits a system built for scale, so the experience leans more utilitarian than a tool made for a single property would.

Challenge 03:

Wide range of end consumer

Solution

A glanceable, accessible interface with large targets, plain language, familiar patterns, clear hierarchy, and no setup for the guest.

Tradeoff:

We keep the guest side deliberately simple, holding back more complex features so every guest understands it on sight.

/System Flow

/System Flow

How the system moves content from Property Management Systems to screens

Before designing a single screen, the CTO and I mapped how content would move through the system. We disagreed on a few things and landed on this.

01

PMS creates the properties

Connecting the PMS pulls in the full portfolio: units, addresses, and reservations. Nothing is entered by hand.

02

Host adds their content

Branding, house info, and local picks, layered on top of what the PMS already knows. AI drafts recommendations per property.

Branding, house info, and local picks, layered on top of what the PMS already knows. AI drafts recommendations per property.

03

Host saves and publishes

Edits auto-save as a draft. Nothing reaches the guest side until the host publishes.

04

Guest opens the TV or mobile

Each surface fetches on open and builds the screen from the reservation plus whatever the host last published.

The PMS was the setup path from the start. It already knows every unit, address, and booking, which is why onboarding 500 properties costs about what onboarding one does.

Where we disagreed

Manual setup for hosts without a PMS

Our CEO and CTO wanted to support hosts without a PMS at launch. I pushed back, since no reservation data means no guest names and no automatic setup. We shipped PMS-only.

Later, hosts without a PMS wanted the product anyway, and we found other routes to the data. I'd assumed it wouldn't be worth much without reservation data. I was wrong.

Auto-save

Our CTO wanted an explicit publish step for a cleaner data model. I argued hosts would lose work if we only saved on publish. We do both: edits auto-save as a draft, and nothing reaches the guest until the host publishes.

/Onboarding

Creating the same onboarding experience regardless of property size

Once a host enters an API key, the PMS supplies everything WelcomeScreen needs to set a property up. That meant a host could see their whole portfolio in the product within a minute of connecting, before typing anything.

01.

Select properties

Hosts often want WelcomeScreen on specific properties only, so the import starts with filtering what comes over from the PMS.

02.

Confirm what transfers

Showing exactly which data moves across, so nothing arrives unexpected.

03.

Import runs

A short loading state that names what's being matched rather than showing a bar alone.

04.

Pair a screen

Hosts land on the property list ready to pair. Anything incomplete is flagged rather than blocking, since one missing wifi password shouldn't hold up the other 95.

Property listing section with grid vs list forma

Hosts land here with the portfolio already built. Screens get paired one at a time as devices go in, which keeps setup and installation independent of each other.

/Designing the TV experience

The first screen a guest sees, and the decisions behind it

A guest arrives with no account, no instructions, and about ten seconds of patience. A host wants their brand on screen, their own words, their recommendations, across every property they own. Those two things pull against each other, and this screen is where they had to be reconciled.

01.

Host logo

Fixed to the top left on every screen, so the host's brand is always present and never has to be placed.

02.

Name from the reservation

Automated so a host can greet every guest by name without writing anything, at any portfolio size.

03.

Personalized message

Written once and applied across hundreds of properties, or edited for a single stay when the occasion calls for it.

04.

Focus arrives already set

Glow and 1.05 scale. The first action is focused as soon as the screen loads, so a guest doesn't have to look for where to start.

05.

Blur and gradient

Hosts choose the photo, so contrast can't be left to it. The blur keeps text legible on any image.

06.

Safe zone

A 5% inset on every edge. Panels crop the outer border, so nothing sits outside it.

Built for whatever language the host writes in

Our first international customer operated in Australia and asked about temperature units. We hadn't considered it, so we added it as an option.


Full localization never became a priority. Most of our customers were in English-speaking countries, and doing it properly meant taking on layout work we couldn't justify. The guest side also leaned on common patterns and icons, so the core functionality worked regardless of the language someone spoke.


Property managers kept control of what displayed. Units default from the property address and can be overridden, and content appears in whatever language they write in, so a host operating in Korea wrote in Korean and that's what guests saw.

Designing for a device in someone's hand

There's no cursor on TV. Focus is always somewhere, only ever on one thing, and a guest moves it one element at a time in four directions. Every action had to sit on an obvious path from wherever they already were.


Every element the host added is one more thing a guest has to move past with four arrow keys. The more control hosts get, the longer the path to what a guest actually came for.

Left and right move across the top navigation.

Down enters the list, and focus moves one item at a time.

back Returns focus to the current tab rather than leaving the app, so a guest can't exit by accident.

/Incorporating AI features

We added AI to the two things no host could keep up with manually.

Competitors were adding AI, so we looked for where it would actually matter rather than adding it for its own sake. Two places qualified: work that was location dependent and repetitive enough that no host could keep up with it manually. Recommendations and guest questions both fit.

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 lives inside the mobile guidebook. Guests ask questions about the property and get answers pulled from the host's own content, so nothing is invented. We've since added local area awareness and photo recognition.

Both features are opt-in, and roughly 35% of properties have used them since launch.

/Design System

/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.

Foundation

Foundation

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 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.

Tokens

Tokens

01 Primitive

Holds the value

Referenced only. Never applied directly to anything.

02 Semantic

Carries the intent

Named by use case, so an engineer knows what it's for.

03 Component

Scoped to one place

Exists only where a real constraint forces divergence.

The property card shows this in practice, built entirely from semantic and component tokens, with optional elements controlled through toggles rather than separate builds.

Component

Component

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.

/Outcome

/Outcome

Trusted by property managers across the globe

Reached

4,500+

Properties live

Trusted by

850+

Property Operators

Coverage

35+

Countries

Scale

1M+

Guest interactions annually

Surfaces Designed

Desktop

TV app

Mobile

Features owned

Desktop host portal

Interactive TV layout

Mobile guidebook

AI recommendations

Host storefront set up

Analytics dashboard (shipped, pulled)

AI concierge

The operator's presence, in a building they aren't in

WelcomeScreen went from nothing to 4,500 properties and over a million guests a year, in eighteen months. The reference point was the hotel TV, but a hotel has a front desk and a rental has nobody in the building. What we built was the operator's presence in a place they aren't.

What we pulled back

The analytics dashboard shipped and came out again. It was built on an assumption I never examined, that hosts wanted visibility into their own performance, when what it actually did was tell someone their property sat empty for nine days inside the product they were paying for. Conversion and retention both moved the wrong way that month, so I recommended pulling it.

/Reflection

/Reflection

Hosts want maximum control and customization. Guests need simplicity, clarity and accessibility.

Designing for two different user type meant sometimes protecting one from the other. Hosts wanted more control over every screen, and every addition cost the guest something. The hard decisions were about where to stop.

There's a second line I'm less sure I drew right. Most accounts run one or two properties; the ones that drive revenue run dozens. Designing down from the large operator meant the majority inherited a system built for someone else.

Selected Work.

Selected Work

Selected Work.