Caso de estudio UX
Agregar el pago posterior a un flujo de reserva de hotel
Findhotel ya tenía habitaciones en su portafolio que el viajero paga en el hotel y no en el checkout. Lo que no tenía era una forma de elegir eso al reservar. Esta es la primera versión de esa elección, y el experimento de cinco semanas que midió cuánto valía.
La elección, donde acabó: en la página de selección de habitación, antes del checkout. No donde yo la quería, y la razón está más abajo.
Problema
¿Por qué este proyecto?
Findhotel es un jugador más chico en hospedaje y atiende los mercados locales que Booking, Expedia y TripAdvisor suelen dejar de lado. Buena parte de su portafolio es inventario que el hotel no espera vender y que no puede listar por su cuenta sin que las plataformas grandes lo bajen de prioridad. Pagar en el hotel en lugar de en el checkout es una de las cosas que pueden distinguir a una plataforma así de las que están por encima.
Así que el caso de negocio nunca estuvo en duda. Lo que sí estaba en duda era todo lo demás. Permitir que un viajero pagara después implicaba conseguir el portafolio de hoteles correcto, reestructurar cómo se manejaban las reservas y, al final de todo eso, darle a alguien una forma de elegirlo. De esa última parte trata este caso, y fue más difícil de lo que suena.
El problema real era que el pago posterior podía irse en mil direcciones. Todos tenían una opinión sobre cómo debía verse y sobre qué correspondía a una primera versión. Introducir una función a través de varios equipos scrum es difícil en cualquier organización; es bastante más difícil cuando se espera que esa función mueva la conversión del producto principal, porque entonces todos tienen razón en opinar. Algo tenía que zanjarlo.
Algo que esta página no puede contarte es qué dijo un viajero que quería, porque nadie lo anotó. El caso que existe en papel es el comercial, y sería deshonesto reconstruir ahora la otra mitad.
Objetivos
Resultado deseado
Sabíamos que la función sería bien recibida. Lo que nadie sabía era cuánto, y la primera versión se diseñó alrededor de ese hueco.
Esos tres son un solo objetivo con tres sombreros. Un producto mínimo viable aquí no era una forma de trabajar menos; era la única forma de obtener un número, y un número era lo único que compraría el argumento para una segunda ronda. Todo lo que yo hubiera preferido diseñar dependía de eso.
Equipo & audiencia
¿Quién lo construyó y para quién?
Cómo estaba formado el equipo
Nuestro product owner aportó el caso de negocio y las prioridades. Nuestro científico de datos aportó los números contra los que se tomaron las decisiones y diseñó la prueba A/B, lo cual importa más de lo que suena: una prueba diseñada por quienes quieren una respuesta específica no es una prueba.
Un redactor dedicado escribió los textos. Una agencia externa los tradujo. Yo era el único diseñador en la función, y los desarrolladores eran un equipo scrum dentro de una organización que tenía varios.
Mis responsabilidades
Hacer benchmark de la competencia, dirigir las sesiones de ideación y de alcance del equipo, hacer wireframes, construir un prototipo lo bastante de baja fidelidad como para discutirlo, probarlo en guerrilla, convertir el resultado en un plan de desarrollo y dibujar las pantallas de alta fidelidad contra el sistema de diseño.
Después de eso: mantener los textos apuntando a lo que medía la prueba, probar el build a mano contra cada escenario acordado, ver sesiones reales una vez en vivo y documentar todo para colegas que nunca estuvieron en la sala.
Audiencia
¿Para quién construimos esto?
Primero quienes hablan inglés, y esa decisión la tomaron por nosotros. El sistema de traducción de entonces era tan lento que meter textos nuevos en las semanas que teníamos no era realista, y de todos modos se esperaban varias rondas de ajuste.
Así que las primeras semanas de la prueba salieron solo en inglés. Un viajero angloparlante veía todo el flujo en su idioma. Un viajero coreano, tailandés o danés veía el resto del sitio en el suyo y la terminología de pago posterior en inglés, que es algo genuinamente raro de poner enfrente de alguien a media compra. Lo que lo hacía defendible era la forma de la audiencia: los usuarios estadounidenses son por mucho el grupo más grande de la plataforma, así que quienes verían la función completa eran también quienes tenían más probabilidad de verla.
Alcance y limitaciones
Limitaciones
Tres restricciones moldearon esto más que cualquier decisión de diseño que yo tomara.
La primera es la de arriba: textos en dos idiomas a media compra, para todos los que no hablan inglés.
La segunda fue la página de búsqueda. Si un hotel aceptaba pago posterior, los resultados debían decirlo, y ahí es donde un viajero decide qué hotel abrir. La página de búsqueda pertenecía a otra parte de la organización y no pudo cambiarse a tiempo para la prueba. Vale la pena decir el resultado sin rodeos, porque reaparece al final de esta página: un viajero buscando en Findhotel veía ofertas con pago posterior de Booking, Agoda y Expedia en los resultados, y ninguna de Findhotel, incluso donde Findhotel sí las tenía.
La tercera fue la página de checkout, donde una limitación técnica de la arquitectura descartaba cualquier cosa que no fueran cambios mínimos. Eso quitó de la mesa varios diseños que yo prefería y dejó exactamente un lugar donde el viajero podía elegir: la página de selección de habitación. Pedirle a alguien que se comprometa con un esquema de pago antes de llegar al checkout es raro, en el mejor de los casos. Era la versión que podía salir, y sacar algo medible era todo el punto.
Proceso
Descripción paso a paso
Lo que sigue es una versión de una función, no la historia del pago posterior en Findhotel. Es la primera, y la que tenía que ganarse el resto.
Mapeo de escenarios
Antes que nada, un mapa aproximado de lo que un viajero podía hacer y qué pasaría entonces. No un flujo de la ruta ideal: un abanico de resultados, incluidos los que nadie quiere.
La razón para dibujarlo primero es que el plan de desarrollo posterior no será mejor que esto. Mapear los escenarios por adelantado es como los casos límite se vuelven decisiones de diseño y no bugs encontrados en el último sprint. No atrapa todo, y este tampoco lo hizo.
Cada interacción y lo que se sigue de ella. Los casos límite son el punto de este dibujo, no el centro.
Benchmark de la competencia
Todos los jugadores grandes del hospedaje, y varios chicos, desarmados pantalla por pantalla. El objetivo era un conjunto de hallazgos accionables para el equipo: en qué se había asentado la industria, dónde estaban los huecos y cuáles de nuestros argumentos ya los había respondido alguien con más tráfico que nosotros.
Tuvo un segundo efecto que no planeé. Recorrer los flujos de otros levantó más preguntas sobre la industria de las que respondió, y varias de ellas se repartieron entre otros miembros del equipo para investigarlas. Para eso sirve mirar cómo lo hacen los demás: es exploratorio, y lo útil suele ser la pregunta y no la copia de la respuesta.
Booking.com y Expedia. Las dos plataformas más grandes en hospedaje, y las dos que más vale estudiar.
Ideación y alcance
Yo dirigí las sesiones de ideación, y el benchmark fue la razón por la que funcionaron. Una sala llena de gente con opiniones fuertes sobre una función es una sala difícil; una sala llena de gente a la que acaban de mostrarle qué lanzaron realmente cinco competidores es otra cosa. El material hizo la discusión.
El trabajo de alcance corrió en paralelo, con el product owner y el científico de datos. Dos preguntas, separadas a propósito: cuál sería la versión ideal de esto y cuál es la versión más pequeña que vale la pena poner frente a alguien. Sostener ambas significó que los recortes quedaran registrados como recortes en lugar de perderse, que es lo que hace posible una segunda ronda.
Wireframes, y probarlos en el pasillo
El wireframe se volvió un prototipo clicable, y su tarea era poner dos conceptos rivales en una forma que alguien pudiera tomar en la mano. Una opinión sobre un diagrama es barata. Una opinión sobre algo por lo que acabas de hacer clic vale la pena, y llega antes.
De baja fidelidad a propósito, porque la audiencia eran las partes interesadas y cualquiera en la organización con interés en el resultado, y una pantalla pulida invita a conversar sobre el pulido. Luego pruebas de guerrilla, para eliminar los problemas obvios antes de que le costaran un sprint a alguien y para sacar a la luz las preguntas que levantaba el concepto. Varias de ellas regresaron al equipo para investigarse a fondo.
La pantalla sobre la que gira toda la función, en la forma en que se discutió por primera vez. Dos maneras de pagar la misma habitación al mismo precio, una debajo de la otra, y nada más en la pantalla sobre lo que discutir.
El plan de desarrollo
Un solo dibujo con la ruta ideal, los casos límite principales y la pantalla en la que aterriza cada uno. A partir de eso, el product owner y los desarrolladores podían escribir tickets sin volver a preguntar qué pasa cuándo.
También zanjó algo que el diseño no podía decidir solo. Nuestra arquitectura corría con los datos de Expedia para esta versión, lo que implicaba ajustarse a las reglas de Expedia sobre cómo se procesa una reserva después del checkout. Así que leí esas reglas y las volví a dibujar como un flujo de decisión que un colega no técnico pudiera seguir, lo cual resultó tan útil para los desarrolladores como para cualquiera: hizo visible qué subfunciones estábamos heredando y cuáles elegíamos no implementar todavía.
Cada pantalla que tenía que cambiar y qué tenía que cambiar en ella.
Qué le pasa a una reserva después del checkout, según las reglas que heredamos. Aquí recortado; se abre completo.
Pantallas de alta fidelidad
Una vez que existían los tickets, las pantallas se dibujaron contra la guía de estilo y la biblioteca de componentes de Findhotel, de modo que el desarrollador front-end implementara una maquetación en lugar de interpretarla. Paddings, colores, márgenes e iconos salieron todos del sistema. Las pantallas clave para escritorio y móvil se publicaron en Zeplin para que los desarrolladores trabajaran desde ahí.
Probarlo a mano, antes del lanzamiento
En cuanto los desarrolladores tenían algo sin lanzar, recorría a mano los escenarios que habíamos acordado para ese sprint. Aquí es donde el mapa de escenarios y los diagramas de alcance pagan su costo: sin ellos, "¿probamos todo?" es una cuestión de memoria.
Junto con los escenarios, el equipo revisó el mismo build contra cada uno de estos puntos, donde aplicaran. Es una lista larga para una función tan pequeña, y esa es la forma honesta de meter una elección de pago en un embudo de reserva que ya existe.
- Dispositivo móvil, tableta, escritorio
- Navegador Chrome, Safari, Firefox, Edge
- Duración de la estancia una noche frente a varias
- Configuración de habitaciones una habitación frente a varias
- Con sesión iniciada frente a sin sesión
- Ofertas privadas presentes, ausentes y mezcladas
- Disponibilidad disponible, agotado, precio que no coincide
- Impuestos mostrados por separado, como en EE. UU., frente a incluidos, como en los Países Bajos
- Desglose de pago precios que incluyen impuestos y cargos a pagar en el hotel frente a precios solo de pago ahora
- Moneda convertida desde el proveedor frente a sin convertir
- Idioma inglés frente a alemán, que es más largo y rompe las maquetaciones primero
Observarlo en su ambiente
Una vez en vivo, la pregunta deja de ser si funciona y pasa a ser qué hace la gente realmente con ello. Para eso usé FullStory, que graba sesiones reales y permite segmentar por comportamiento o por ubicación. Cuando encontraba un problema, un bug o una idea que valiera la pena guardar, la anotaba. Los bugs se cuelan, y las interfaces hacen cosas raras en ciertos navegadores; así te enteras de cuáles.
Cinco sesiones, guardadas porque cada una muestra algo que los números no pueden. Dos están del lado A y tres del lado B de la prueba.
Taiwán, escritorio, lado A
India, escritorio, lado B
Ohio, phablet, lado B
Catar, móvil, lado A
España, tableta, lado B
Documentarlo para los demás
El último paso, y el más fácil de saltarse. Un experimento que solo entiende su propio equipo no le ha dicho nada a la empresa.
El product owner y el científico de datos escribieron el relato legible. Lo que yo hice fueron los dos dibujos de abajo: los dos lados de la prueba, lado a lado, para que un colega que nunca estuvo en una de nuestras juntas pudiera pasar de largo y ver en unos segundos exactamente qué se había cambiado.
Conclusión
Resultados
Conversión en ofertas de Expedia, las únicas de la prueba. Esa cifra ya está neta de la mayor tasa de cancelación de abajo, así que es lo que valió la función después del costo de las reservas que perdió.
Cancelaciones en reservas con pago posterior frente a las de pago ahora. No es sorpresa, y no es gratis: de una reserva que alguien no ha pagado es más fácil desistir. Es el precio de la conversión de arriba.
Y luego la parte menos cómoda de publicar. Un bug en la página de búsqueda hacía que solo se mostraran los tres primeros proveedores por cada hotel, y las propias ofertas de pago posterior de Findhotel no siempre estaban entre ellos. Así que una proporción desconocida de los viajeros de esta prueba no podía encontrar aquello que se estaba probando.
Lo que significa que el número de arriba es un piso y no una medición. La función probablemente valía más de 4.2%, y la versión honesta de esa frase es que no sabemos cuánto más. La página de búsqueda se arregló después, pero la prueba nunca se volvió a correr contra una versión corregida, así que el techo sigue sin medirse. Lo que la prueba sí estableció es una dirección, y una dirección bastó para justificar el trabajo que vino después.