Caso de estudio · Jun 2025

FlySplit

Acumular horas de vuelo le cuesta a un piloto español en formación más de 70.000 €. Diseñé una app de dos perfiles que reparte ese coste con pasajeros, dentro de lo que permite la ley europea.

Rol

UX/UI Designer & Researcher

Duración

3 meses · 300 horas

Herramientas

Figma · Optimal Workshop · Google Forms · UXPressia

Metodología

Diseño Centrado en el Usuario (UCD)

Resumen ejecutivo

FlySplit es una app móvil nativa que conecta pilotos en formación con pasajeros para compartir los costes directos de vuelos privados, reduciendo el coste del time building en un 30–40% estimado y abriendo la aviación privada a más gente.

En 3 meses y 300 horas, lideré el proceso UX completo: investigación normativa, encuestas a 81 participantes, 8 entrevistas en profundidad, tree testing con Optimal Workshop y prototipado iterativo de alta fidelidad. En la ronda final de usabilidad, los cuatro participantes (2 pilotos, 2 pasajeros) completaron todas las tareas, con puntuaciones SUS de 97,5 en pilotos y 90 en pasajeros — orientativas dado el tamaño de la muestra, pero coherentes con lo observado en las sesiones think-aloud.

El problema

Convertirse en piloto comercial en España supera los 70.000€. El "Time Building" (acumulación de horas de vuelo) supone un 30–40% estimado de este coste. A pesar de la demanda del sector, esta barrera económica impide a muchos candidatos acceder a la profesión.

La solución

FlySplit es una app nativa de economía colaborativa (estilo BlaBlaCar) que conecta a pilotos con pasajeros para dividir equitativamente los costes directos del vuelo, combustible, tasas y alquiler, abaratando la formación del piloto y dando a los pasajeros acceso a la aviación privada a un coste compartido y transparente.

Investigación

Desk research legal

El análisis exhaustivo de la normativa AESA y EASA confirmó la base legal para compartir costes en vuelos privados no comerciales. Los pilotos pueden recuperar los costes operativos directos, combustible, tasas de aterrizaje y alquiler, sin que la actividad se clasifique como operación comercial, siempre que no exista ánimo de lucro. Esa claridad legal le quitó riesgo al concepto antes de invertir nada más.


Benchmark competitivo

Wingly (líder del mercado europeo) y Coavmi fueron mapeados como competidores directos. El benchmark reveló puntos débiles recurrentes: cálculos de reparto opacos, políticas de cancelación mal comunicadas, canales de atención limitados y ausencia de verificación de identidad o seguridad. Estos pain points definieron directamente la propuesta de valor de FlySplit.

FuncionalidadWinglyCoavmiFlyshareDreamairYumping
Chat (piloto ↔ pasajero)
Pago integrado
Filtros de búsqueda avanzados
Mapa de vuelo interactivo
App móvil nativa
Validación de licencia
Sustitución de piloto (cancelación)
Reparto de costes
Coste específico por miembro
Perfil hangar de aeronaves

Encuestas de validación

Una encuesta a 81 participantes confirmó la viabilidad del modelo de vuelos compartidos, pero evidenció necesidades críticas en torno a la confianza, la seguridad y la previsibilidad.

Muestra demográfica

Pasajeros62%
Pilotos30%
Otros8%

Funciones de IA más valoradas

Weather cancellation prediction80% · 59 votos
Route & flight suggestions62% · 46 votos
Autonomous support chatbot53% · 39 votos

Funcionalidades más demandadas

Validación de licencias

92%
88%

Validación de identidad

92%
80%

Política de cancelación clara

83%
84%

Evaluación a pilotos

88%
84%

Evaluación a pasajeros

88%
66%
Pilotos
Pasajeros

Entrevistas en profundidad

Realicé 8 entrevistas en profundidad (4 pilotos, 4 pasajeros). El affinity mapping sacó a la luz el hallazgo que marcó todo lo demás: ambos lados querían compartir vuelos, pero a cada uno le frenaba un miedo distinto. Los pilotos temían a Hacienda; los pasajeros, por su seguridad.

La perspectiva del piloto

Acumular horas de vuelo es muy caro (>70.000€), así que los pilotos quieren compartir costes. Su mayor fricción es el riesgo legal y fiscal de ser acusados de obtener beneficio. También tienen necesidades operativas estrictas, como conocer el peso exacto del pasajero para los cálculos de seguridad.

"Hacienda, aunque repartamos costes al 50 %, no lo entiende. Necesitamos garantías legales."

Piloto comercial

"Suena políticamente incorrecto, pero siempre tenemos que pedir el peso del pasajero. Es crucial para el peso y balance de la aeronave."

Piloto en formación

La perspectiva del pasajero

Los pasajeros valoran mucho la experiencia única y el ahorro frente a vuelos tradicionales. Su principal barrera es la confianza: necesitan transparencia total sobre la experiencia del piloto, licencias en vigor y mantenimiento de la aeronave antes de subir.

"Sobre todo, necesito saber que tiene el título que le acredita como piloto y que entiende el espacio aéreo en el que se mueve."

Pasajera potencial

"Me daría igual, al final uno entiende que en un avión pequeño el peso importa, entonces está bien que me lo pidan."

Pasajero potencial

Cómo influyó en el diseño

Cada miedo se tradujo en una respuesta de diseño concreta. La exposición legal de los pilotos llevó al desglose de costes transparente, construido para demostrar que no hay ánimo de lucro (la línea legal del vuelo compartido), y a la verificación obligatoria de licencias. El miedo de los pasajeros por su seguridad llevó a la verificación de identidad y a la declaración de peso en la reserva, porque un plan de vuelo preciso empieza por pesos precisos. Ninguna es una función genérica de confianza: cada una responde a un miedo que alguien verbalizó en una entrevista.

Definición

Personas de usuario

Dos tarjetas de User Persona muy completas sintetizan biografía, personalidad, estilo de vida, habilidades, motivaciones, objetivos y frustraciones de cada perfil clave.

Piloto en formación

PEDRO GUTIERREZ

Necesito algo confiable para reducir gastos sin sacrificar horas de vuelo.

Edad

24 años

Género

Hombre

Estudios

PPL

Ocupación

Estudiante ATPL

Biografía

Se encuentra en la fase de Time Building, enfocado en fortalecer sus habilidades mediante la inversión de tiempo y recursos en formación especializada. Con determinación, busca oportunidades para participar en vuelos y simulaciones que le permitan acumular horas de experiencia y consolidar su trayectoria.

Habilidades

  • Conocimientos sólidos de aviación.
  • Sigue procedimientos y normas de seguridad.
  • Comunicación con pasajeros e instructores.

Objetivos

  • Obtener licencia comercial.
  • Acumular horas económicamente.
  • Encontrar trabajo como piloto.
  • Financiar formación y licencias.
  • Conectar con otros pilotos.

Frustraciones

  • Altos costes de formación y alquiler.
  • Pocas oportunidades de vuelo asequibles.
  • Incertidumbre sobre el futuro de su carrera.

Mapa de customer journey

Cinco etapas, de la concienciación a la fidelización, recogen acciones, pensamientos y emociones de cada rol.

Piloto en formación

PEDRO GUTIERREZ

Escenario

Pedro debe sumar 50 horas de time building y los costes se le disparan. Usa la app para compartir plazas en rutas escénicas o viajes cortos y repartir gastos mientras practica.

Concienciación

Acción

Investiga formas de reducir los altos costes de su time building.

Pensamiento

¿Existe una forma de reducir mis gastos sin sacrificar horas de vuelo? Necesito algo confiable.

Emoción

Preocupación

Evaluación

Acción

Explora la app para verificar la legalidad (normativa AESA) y el sistema de cobros.

Pensamiento

¿Cómo aseguro que los pagos sean transparentes frente a Hacienda?

Emoción

Anticipación

Consideración

Acción

Publica su primer vuelo y resuelve dudas de los pasajeros por el chat integrado.

Pensamiento

¿Cómo hago mi anuncio más llamativo? ¿Serán los pasajeros respetuosos con el peso y las normas?

Emoción

Optimismo

Uso

Acción

Acepta la solicitud, realiza el vuelo y recibe el pago en su monedero virtual.

Pensamiento

¿Los pagos se procesarán sin problemas por parte de la plataforma?

Emoción

Alegría

Fidelización

Acción

Valora a los pasajeros y busca construir una red de clientes recurrentes.

Pensamiento

¿Mis buenas reseñas atraerán a más pasajeros en el futuro?

Emoción

Serenidad

Requerimientos clave

En base a la investigación y los user journeys, se definieron 31 requisitos funcionales, no funcionales y legales. El diseño del Producto Mínimo Viable (MVP) se priorizó en torno a cuatro pilares estratégicos:

Confianza y seguridad

Validación obligatoria de licencias de vuelo y certificados médicos en pilotos, junto a la verificación de identidad en pasajeros. Implementación de un sistema de reseñas bidireccional.

Finanzas transparentes

Cálculo automático y desglose equitativo de los costes directos operacionales (combustible, tasas aeroportuarias, alquiler). Pasarela de pago segura integrada en la plataforma.

Cumplimiento legal

Estricto cumplimiento de las normativas de AESA/EASA para garantizar operaciones sin ánimo de lucro. Visualización clara de los seguros obligatorios de la aeronave.

IA y asistencia

Chat integrado para comunicación directa y funciones impulsadas por IA para la predicción de cancelaciones meteorológicas y sugerencia de rutas.

Ideación

Arquitectura de la información

A partir de los hallazgos de investigación, la AI se estructuró mediante content trees para cada rol y se comprobó con un tree test antes de producir ningún wireframe. La mayoría de tareas clave se localizaron en menos de 3 clics — y el test destapó además dos puntos débiles de la navegación (detallados abajo), mucho más baratos de corregir en esta fase que después del wireframing.

  • Contenido exclusivo para quienes se registran o logean.
  • Contenido exclusivo para quienes hayan validado su identidad.
  • Contenido exclusivo para quienes han validado sus licencias.

Validación del tree test e insights

Para validar la arquitectura de la información inicial, se realizaron dos tree tests mediante Optimal Workshop. Aunque las tareas principales alcanzaron hasta un 100% de éxito, la prueba reveló problemas críticos de navegación que definieron el diagrama de flujo final.

Herramienta de tree testing

Optimal Workshop

Tasa de éxito general

Hasta 100%

Insights del piloto

El problema

Los pilotos tuvieron grandes dificultades para encontrar la opción de "Cancelar vuelo" y la sección del "Monedero / Saldo" (solo un 33% de éxito).

Acción tomada

La acción de cancelación se destacó visualmente dentro de la pestaña de "Próximos vuelos". El monedero se movió a un área principal más accesible dentro del Perfil para garantizar su visibilidad inmediata.

Insights del pasajero

El problema

Los pasajeros experimentaron confusión al intentar configurar las alertas de vuelos y al separar el proceso de reserva del proceso de pago (50% de éxito).

Acción tomada

Los ajustes de notificaciones se agruparon en una pestaña dedicada y más clara. El flujo de pago se rediseñó por completo para clarificar el modelo de "Reserva ahora, paga tras la confirmación del piloto".


Flujos de usuario

Se crearon mapas de flujo detallados para el camino principal de cada rol.

  • Inicio del flujo
  • Decisiones
  • Acciones
  • Fin del flujo

Diseño

Evolución del diseño

De los bocetos en papel al prototipo interactivo de alta fidelidad en tres pasadas, con enfoque Mobile First y testeando con usuarios reales por el camino.

01. Sketches

Debido a la limitación de tiempo y al tratarse de un producto nuevo, se priorizó un enfoque estricto "Mobile First". Se realizaron bocetos en papel para visualizar rápidamente el "Happy Path" de los flujos del piloto y el pasajero.

02. Wireframes

Se testearon wireframes en Figma mediante la técnica "Think Aloud". Aquí se detectó una fricción crítica: condicionar el pago a una reseña post-vuelo generaba desconfianza. Para solucionarlo, diseñé un sistema de confirmación presencial mediante código PIN.

03. UI Kit & Branding

La identidad refleja su propósito: el Azul (#2A5C9D) simboliza el cielo (Piloto), y el Verde (#4CAF50) la tierra (Pasajero). La interfaz se construyó siguiendo Material Design, aplicando las leyes de Fitts y Hick para garantizar accesibilidad.


Prototipo Hi-Fi: en qué quedó la app

Una aplicación móvil nativa dividida en dos experiencias a medida, diseñada para que compartir un vuelo privado se sienta tan claro y legítimo como reservar uno comercial.

Piloto

Publicación inteligente

Los pilotos configuran fácilmente la ruta, aeronave y costes directos (combustible, tasas, etc.). La aplicación calcula automáticamente el precio equitativo por pasajero, cumpliendo estrictamente con la normativa de AESA/EASA para evitar el ánimo de lucro.

Ambos usuarios

Reserva y pago seguro

El flujo comienza con la reserva de la plaza por parte del pasajero, facilitando sus datos. Una vez que el piloto revisa los perfiles y acepta la reserva, el pasajero recibe la confirmación y procede a realizar el pago seguro a través de la pasarela integrada.

Ambos usuarios

Rastreo y verificación por PIN

El día del vuelo, el piloto debe introducir un PIN único de 4 dígitos proporcionado por el pasajero. Esto asegura el encuentro presencial y da comienzo al seguimiento del vuelo en tiempo real en el mapa.

Ambos usuarios

Monedero virtual y evaluación

Tras el aterrizaje, ambas partes evalúan la experiencia. En un plazo máximo de 48 horas, el piloto recibe el dinero de la reserva en su monedero virtual, listo para ser retirado o usado en futuros vuelos.

Test

Evaluación heurística

Antes de las pruebas con usuarios reales, se realizó una mesa redonda presencial con 4 profesionales del sector Tech y UX/UI. El prototipo se evaluó frente a los 10 principios heurísticos de Nielsen, identificando y solucionando fricciones críticas en el flujo.

Principio de NielsenProblemaSoluciónImagen del cambio

Control y libertad del usuario

Problema:

El usuario no tenía forma de eliminar imágenes o puntos turísticos subidos por error al crear un vuelo.

Solución:

Se integraron iconos de eliminación ("X") claros para devolver el control total de la acción al usuario.

Prevención de errores y eficiencia

Problema:

Si el piloto cerraba por error el modal de "Comenzar vuelo", perdía el acceso al PIN necesario para la ruta.

Solución:

Se implementó un overlay permanente minimizado en la parte inferior para evitar la pérdida de esta información crítica.

Consistencia y estándares

Problema:

Había redundancia en la navegación (flecha de retroceso superior frente al botón inferior de "Atrás").

Solución:

Se eliminó la redundancia y se estandarizó un botón de "Cancelar" que activa un aviso de pérdida de datos para evitar salidas accidentales.

Visibilidad del estado del sistema

Problema:

Faltaba correspondencia visual clara entre la lista de puntos turísticos y sus marcadores en el mapa de ruta.

Solución:

Se añadieron indicadores numéricos en la lista que se vinculan exactamente con los marcadores del mapa.


Pruebas de usabilidad

Cuatro usuarios reales (2 pilotos y 2 pasajeros) completaron escenarios de tareas de principio a fin utilizando la técnica "Think Aloud" mediante Google Meet. El objetivo era validar el flujo del "Happy Path" y detectar posibles fricciones.

100%

Tasa de éxito en tareas · los 4 participantes, todos los escenarios

97.5/100

Puntuación SUS, pilotos · Rango "Excelente" · n=2

90/100

Puntuación SUS, pasajeros · Rango "Bueno-Excelente" · n=2


Iteraciones de diseño: escuchando a los usuarios

Terminología de costes

Feedback

A los pilotos les resultaba confuso y poco estándar el desglose de tasas de "aterrizaje", "aparcamiento" y "rampa".

Solución aplicada

Se consolidó la terminología en conceptos estándar del sector: "Tasas aeroportuarias" y "Coste de handling", simplificando la publicación del vuelo.

Seguridad y planes de vuelo

Feedback

Los pilotos destacaron que necesitaban el DNI/Pasaporte de todos los pasajeros antes del vuelo para poder rellenar legalmente la hoja de ruta.

Solución aplicada

Se actualizó el flujo de reserva para que el campo del DNI del acompañante sea obligatorio antes de enviar la solicitud.

Comunicación piloto-pasajero

Feedback

Los pilotos mencionaron que suelen enviar las mismas instrucciones repetitivas (puntos de encuentro, normas) a todos los pasajeros.

Solución aplicada

Se añadió un sistema de plantillas de mensajes rápidos (incluyendo opciones generadas por IA) en la pantalla de confirmación del vuelo.

Flexibilidad de programación

Feedback

Los pilotos indicaron que suelen reservar avionetas para días concretos, por lo que la función de "disponibilidad recurrente" era insuficiente.

Solución aplicada

Se añadió un modo de "Fecha Específica" con calendario integrado en el flujo de publicación de vuelos.

Prototipo interactivo

Un mismo vuelo, dos apps distintas. Explora el diseño final de alta fidelidad y usa el selector para recorrer el "Happy Path" desde cada lado.

Piloto

Conclusiones

Ideas clave

FlySplit validó un modelo colaborativo legalmente sólido bajo el Reglamento (UE) 965/2012: el reparto de costes es legal siempre que se dividan únicamente los costes directos entre un máximo de seis ocupantes y no exista ánimo de lucro. Esa claridad normativa se convirtió en una restricción de diseño fundamental.

Más allá del cumplimiento normativo, la economía es el argumento: el time building es una de las mayores barreras para acceder a la profesión, y repartir los costes directos la recortaría en un 30–40% estimado. Esa cifra es una estimación construida sobre la estructura de costes que afloró en la investigación, no un resultado medido — validarla en producción sería el siguiente paso.

Con una muestra de solo cuatro personas, leo las puntuaciones SUS de arriba como dirección y no como prueba. La señal fuerte fue ver a los dos perfiles completar el flujo entero sin ayuda.

Lo que aprendí

El aprendizaje más importante fue estructural. Pilotos y pasajeros comparten la misma plataforma pero necesitan cosas opuestas: los pilotos necesitan transparencia legal y financiera para protegerse ante Hacienda; los pasajeros necesitan señales de confianza para sentirse seguros subiendo con un desconocido. Esa dicotomía condicionó cada decisión de diseño, desde el flujo de onboarding hasta la pantalla de confirmación de reserva.

También aprendí que diseñar para un nicho regulado significa absorber su lenguaje. Pasar de términos genéricos a "tasas aeroportuarias" y "handling" fue una decisión legal y de confianza. El campo obligatorio del DNI del acompañante no vino de un principio de diseño; vino de un piloto real explicando qué ocurre si el plan de vuelo está incompleto.

Por último, el PIN de 4 dígitos para verificar el encuentro presencial antes de iniciar el tracking sigue siendo una de mis soluciones favoritas del proyecto, una interacción pequeña que resuelve un problema real de confianza con casi cero fricción.

Siguientes pasos

Unhappy paths y casos límite

Los flujos que no llegué a dibujar: un pasajero que cancela la noche antes, la meteorología que deja el vuelo en tierra y quién le debe qué a quién después.

Escalado multiplataforma

Layouts para tablet y escritorio. En la planificación de ruta la pantalla grande sí se gana el sitio, porque el mapa completo y el desglose de costes caben por fin a la vez.

Integración de IA

Sugerencia de rutas optimizadas, un asistente para las dudas repetidas y predicción meteorológica en tiempo real. Son las tres que la encuesta situó más arriba.