DESARROLLO Y DISEÑO
Diseño UX/UI y desarrollo front en solitario. De Figma a producción.
Diseñado en Figma, desarrollado en Next.js con CSS y Supabase como base de datos. Illustrator para assets gráficos. Mixpanel para analítica de eventos.
Los anfitriones de Airbnb no tienen herramienta para centralizar la información de sus alojamientos. El huésped llega sin contexto, con información desactualizada o dispersa en varios canales.
El problema lo descubrí como huésped. En un alojamiento me dieron un enlace con una guía digital, la idea era buena, pero la información estaba desactualizada, la UX era confusa y el diseño no inspiraba confianza. Ahí vi la oportunidad: la necesidad existía, la solución disponible no estaba a la altura. Los anfitriones resuelven esto hoy con PDFs, mensajes de WhatsApp o notas en papel. Cada canal se desactualiza por separado, genera preguntas repetitivas y hace imposible escalar si tienes más de un alojamiento.
Dos usuarios con objetivos distintos y un loop entre ellos: si el huésped tiene buena experiencia, el propietario se motiva a mantener la guía actualizada.
Desde el inicio identifiqué dos tipos de usuario con necesidades opuestas: el propietario crea y gestiona; el inquilino consume. Pero no son independientes, si el inquilino tiene una buena experiencia con la guía, el propietario se motiva a mantenerla actualizada y a demandar nuevas funcionalidades. Ese loop era el corazón del producto.
Crear la primera propiedad era el flujo más crítico. Si el propietario llegaba a una pantalla de edición vacía y tenía que construir la estructura desde cero, abandonaba. La solución fue que las categorías las define el producto, no el usuario. El propietario llega con categorías ya creadas y selecciona cuáles quiere activar. Nunca parte de una página en blanco.
La primera alternativa explorada fue un sistema de categorías totalmente libre, donde el propietario creaba y nombraba cada categoría desde cero. Lo descarté porque generaba demasiada fricción en el onboarding, el propietario tenía que tomar decisiones de arquitectura de información antes de poder añadir ningún contenido. La segunda alternativa fue plantillas predefinidas por tipo de alojamiento. La descarté porque un anfitrión en Barcelona tiene necesidades muy distintas a uno en un entorno rural. Cualquier plantilla fija iba a ser demasiado genérica o demasiado específica. La solución fue un sistema de categorías fijas curadas por el producto, que el propietario activa o desactiva según su contexto. Las categorías crecen con el producto, parking y lockers se añadieron después del lanzamiento al detectar necesidades reales de los usuarios.
Categorías fijas definidas por el producto, no por el usuario. Esa decisión elimina fricción en el onboarding y convierte cada nueva categoría en una mejora que todos los propietarios reciben sin esfuerzo.
El propietario no crea categorías, las activa. Las categorías las define el producto y crecen con él. Esto elimina la fricción de onboarding y garantiza consistencia entre guías. Cuando se añade una categoría nueva al sistema como parking o lockers, todos los propietarios la tienen disponible automáticamente.
Todo el contenido de una guía cae en uno de dos tipos: información textual como manuales, normas u horarios, o referencias de lugar como restaurantes, hospitales o transporte. Nombrarlos como Info y Location no es solo taxonomía, es la base de la arquitectura de componentes. Cada tipo tiene sus propios componentes de contenido, pero el menú de navegación es el mismo para ambos.
Propietario e inquilino comparten sistema visual, pero el dashboard de edición está optimizado para acción rápida, acceso directo a edición, estado visible de cada sección. La vista del huésped está optimizada para lectura y orientación, sin elementos de gestión que generen ruido.
La integración con Maps fue una decisión de producto desde el día uno, no un añadido posterior. Obtener latitud y longitud de cada lugar permite ofrecer recomendaciones con orientación real, distancia, ruta, contexto geográfico, y no solo listas de texto sin referencia espacial.
Componentes reutilizables por tipo de contenido. El diseño se itera en paralelo al desarrollo, cuando se añade una feature, el componente evoluciona con ella.
La distinción Info / Location no es solo de diseño, define directamente la arquitectura de componentes en código. Los componentes de Location son reutilizables para cualquier referencia de Google Maps; los de Info, para cualquier contenido textual. El menú de navegación es un componente único que funciona para ambos tipos sin modificación. A nivel de permisos, el modelo es el mismo para propietario e inquilino, la diferencia está en los permisos de escritura, no en la estructura de datos. En la vista del huésped, las secciones vacías simplemente no se renderizan, sin lógica adicional.
El diseño y el desarrollo avanzan en paralelo, cada nueva feature implica revisar los componentes existentes. Un ejemplo concreto: cuando se añadieron las funcionalidades de Check-in y Check-out, el card de propiedad tuvo que modificarse para acomodar esa información sin romper el layout existente. No fue un fallo de diseño inicial, fue la consecuencia natural de construir un producto vivo donde el diseño evoluciona con las necesidades reales.
Producto en producción con usuarios y propiedades activas desde 2025. El foco actual está en captación, el sistema de pago se pospone deliberadamente para no frenar la adopción.
La app está en producción con usuarios registrados y propiedades activas. Se recogen eventos de uso diarios con Mixpanel. Los anfitriones tienen por primera vez una herramienta centralizada para gestionar y compartir la información de sus alojamientos, sin PDFs, sin WhatsApp, sin información desactualizada.
Con recursos y tiempo, empezaría con investigación real de usuarios antes de diseñar. El producto se construyó desde la experiencia propia y la intuición, eso funciona para arrancar, pero las decisiones de la siguiente iteración deberían estar validadas con propietarios reales, no solo con datos de comportamiento post-lanzamiento.
Usuarios registrados en crecimiento · Propiedades activas · Analítica de eventos diaria con Mixpanel · En producción desde 2025
Validar con usuarios activos si el sistema de categorías genera fricción en el onboarding o si necesita sugerencias más visibles para propietarios que no saben por dónde empezar. El siguiente hito de producto es un sistema de pago y suscripción, que se activará una vez se alcance una base de usuarios suficiente.