DEVELOPMENT AND DESIGN
Solo UX/UI design and front-end development. From Figma to production.
Designed in Figma, built in Next.js with CSS and Supabase as the database. Illustrator for graphic assets. Mixpanel for event analytics.
Airbnb hosts have no tool to centralise their property information. Guests arrive without context, with outdated info scattered across multiple channels.
I discovered the problem as a guest. At a property I was given a link to a digital guide, the idea was good, but the information was outdated, the UX was confusing and the design didn't inspire trust. That's where I saw the opportunity: the need existed, but the available solution wasn't good enough. Hosts currently solve this with PDFs, WhatsApp messages or handwritten notes. Each channel goes out of date separately, generates repetitive questions and makes it impossible to scale across multiple properties.
Two users with different goals and a loop between them: if the guest has a good experience, the host is motivated to keep the guide up to date.
From the start I identified two user types with opposing needs: the host creates and manages; the guest consumes. But they are not independent, if the guest has a good experience with the guide, the host is motivated to keep it updated and to demand new features. That loop was the heart of the product.
Creating the first property was the most critical flow. If the host arrived at an empty editing screen and had to build the structure from scratch, they would drop off. The solution was to have the product define the categories, not the user. The host arrives with categories already created and selects which ones to activate. They never start from a blank page.
The first alternative explored was a fully open category system, where the host created and named each category from scratch. I discarded it because it generated too much friction during onboarding, the host had to make information architecture decisions before being able to add any content. The second alternative was predefined templates by property type. I discarded it because a host in Barcelona has very different needs to one in a rural setting. Any fixed template would be either too generic or too specific. The solution was a system of fixed categories curated by the product, which the host activates or deactivates according to their context. Categories grow with the product, parking and lockers were added after launch when real user needs were detected.
Fixed categories defined by the product, not the user. That decision eliminates onboarding friction and turns every new category into an improvement that all hosts receive effortlessly.
The host doesn't create categories, they activate them. Categories are defined by the product and grow with it. This eliminates onboarding friction and guarantees consistency across guides. When a new category is added to the system such as parking or lockers, all hosts have it available automatically.
All guide content falls into one of two types: textual information such as manuals, rules or schedules, or place references such as restaurants, hospitals or transport. Naming them Info and Location is not just taxonomy, it is the foundation of the component architecture. Each type has its own content components, but the navigation menu is the same for both.
Host and guest share the same visual system, but the editing dashboard is optimised for quick action, direct access to editing, visible status of each section. The guest view is optimised for reading and orientation, with no management elements creating noise.
The Maps integration was a product decision from day one, not an afterthought. Capturing latitude and longitude for each place allows real orientation, distance, route, geographic context, rather than plain text lists with no spatial reference.
Reusable components by content type. Design iterates in parallel with development, when a feature is added, the component evolves with it.
The Info / Location distinction is not just a design decision, it directly defines the component architecture in code. Location components are reusable for any Google Maps reference; Info components, for any textual content. The navigation menu is a single component that works for both types without modification. At permissions level, the data model is the same for host and guest, the difference lies in write permissions, not in data structure. In the guest view, empty sections simply do not render, with no additional logic required.
Design and development move in parallel, every new feature means revisiting existing components. A concrete example: when Check-in and Check-out features were added, the property card had to be modified to accommodate that information without breaking the existing layout. This was not an initial design failure, it was the natural consequence of building a live product where design evolves with real needs.
Product in production with active users and properties since 2025. Current focus is on acquisition, the payment system is deliberately postponed to avoid slowing down adoption.
The app is in production with registered users and active properties. Daily usage events are tracked with Mixpanel. Hosts have for the first time a centralised tool to manage and share their property information, no PDFs, no WhatsApp, no outdated information.
With resources and time, I would start with real user research before designing. The product was built from personal experience and intuition, that works to get started, but decisions in the next iteration should be validated with real hosts, not just post-launch behavioural data.
Growing registered user base · Active properties · Daily event analytics with Mixpanel · In production since 2025
Validate with active users whether the category system generates friction during onboarding or whether it needs more visible suggestions for hosts who don't know where to start. The next product milestone is a payment and subscription system, to be activated once a sufficient user base is reached.