Caso de estudio UX
Mejorar la visualización de precios mediante la claridad
El número que veía un viajero al elegir un hotel y el número que se le pedía al final no eran el mismo, y entre más lejos estaba de Estados Unidos, más se abría esa brecha. Este es el trabajo que desarmó el precio en la página en vez de en la caja, y el experimento que midió si decir más sobre un precio vende más de él.
El panel del que trata toda esta página, en el estado en que terminó. Cada línea debajo de la tarifa de la habitación es dinero que alguien antes conocía por primera vez en el checkout.
Problema
Un precio que crecía camino a la caja
Findhotel es un actor pequeño en hospedaje. Trabaja los mercados localizados que las plataformas más grandes suelen dejar en paz, y buena parte de su inventario es inventario en riesgo: habitaciones que un hotel espera no vender y que no puede listar por su cuenta sin que los sitios más grandes lo empujen abajo en los rankings.
Vender ese inventario significa ganar por precio, y el embudo estaba minando su propio argumento más fuerte. La cifra que se mostraba al elegir una habitación no era la que se pedía dos pantallas después, y los datos mostraban que la pérdida se concentraba justo en esa brecha.
La brecha era más ancha para viajeros fuera de Estados Unidos, porque ahí es donde viven las líneas extra: un impuesto municipal que cobra el ayuntamiento, una tarifa de resort que cobra el hotel, otros cargos locales que varían calle por calle. Nada de eso estaba oculto a propósito. Simplemente aparecía tarde, sin nombre y todo de golpe.
Por una vez, dos argumentos apuntaban en la misma dirección. El negocio quería la tasa de conversión. Yo quería que alguien pudiera responder la pregunta por qué estoy pagando esto y para qué sin abrir una segunda pestaña. No suele haber un proyecto donde esas dos cosas sean el mismo trabajo.
Detalles de la oferta, la única pantalla del embudo cuyo trabajo entero es responder esa pregunta.
Objetivos
Lo que el trabajo tenía que lograr
El tercero es la razón por la que los primeros dos pudieron ocurrir. La visualización del precio está en la ruta de ingresos de cada reserva que toma la empresa, así que cambiarla es un cambio con el que nadie puede estar tranquilo. Poder señalar un despliegue por etapas fue lo que hizo posible la conversación siquiera.
Equipo & audiencia
Quién hizo qué
El product owner trajo el caso de negocio y fijó las prioridades. El científico de datos aportó los números en los que descansaban las decisiones y diseñó las pruebas A/B que los midieron. Un redactor era dueño de la redacción de cada etiqueta, lo cual en un proyecto cuyo tema es qué significan las palabras no es una parte menor. Una agencia externa tradujo esa redacción a los idiomas en que corre el sitio.
Todo entre el problema y la entrega era mío: el benchmark, las sesiones de ideación y de definición del alcance, los wireframes y el prototipo, las pruebas de guerrilla, el plan de desarrollo, las pantallas de alta fidelidad, las pruebas manuales antes del lanzamiento, la observación posterior, y el reporte que permitió a cualquiera en la empresa seguir qué había cambiado.
Ser el único diseñador tuvo una consecuencia útil y una incómoda. La útil es que el precio aparecía igual en cada superficie donde aparecía, porque no había con quién estar en desacuerdo. La incómoda es que nada de lo que dibujé fue revisado nunca por otro diseñador antes de construirse.
El redactor es la persona que nombraría si me preguntan qué hizo la diferencia. Renombrar una línea de una tabla cambió lo que significaba la tabla, y ninguna cantidad de maquetación lo habría logrado.
Audiencia
A quién apuntamos, y en qué orden
El primer lanzamiento fue para viajeros estadounidenses que llegaban desde Google hotel ads a la página de selección de habitación. Ese era el grupo más grande y valioso del sitio, lo que lo volvía la audiencia que valía la pena mejorar y la audiencia con la que valía la pena tener cuidado.
El orden después de eso fue deliberado y no alfabético. Una vez que una hipótesis sobrevivía, el cambio salía al resto de los mercados de habla inglesa, y solo entonces a los otros veintiséis idiomas que el sitio soportaba en ese momento. Cada paso era una apuesta menor de lo que valía el anterior, que es como a un equipo se le permite tocar la ruta de ingresos más de una vez.
Vale la pena señalarlo desde ahora, porque vuelve al final de esta página: el grupo al que apuntamos primero no es el grupo del que vino el resultado.
Alcance y limitaciones
Lo que podíamos alcanzar, y lo que no
La empresa estaba organizada de modo que la página de selección de habitación y todo lo que venía después nos pertenecía, y las páginas de búsqueda y de aterrizaje no. Esa es una frontera dura trazada por la mitad del problema: el viajero forma su expectativa del precio en una pantalla que no teníamos permiso de cambiar, y luego se encuentra con la nuestra.
Tampoco había presupuesto para pruebas moderadas. Se llamó a un puñado de clientes, pero el propósito de esas llamadas era recoger lo que ya les disgustaba de la experiencia actual, no ponerles un prototipo enfrente. Así que la mitad cualitativa de este proyecto es un benchmark y un conjunto de grabaciones de sesión, no un estudio.
La primera tarjeta es la que vale la pena mirar con calma, porque es la diferencia entre cambiar una pantalla y cambiar un producto. Un desglose de precio que solo es honesto en el momento del pago no es honesto; es una divulgación. Así que las mismas filas tenían que sobrevivir más allá del punto donde se mueve el dinero, hasta la pantalla que confirma la reserva y el correo que la sigue.
En este wireframe se resolvió eso. Es la pantalla de confirmación, que lleva el mismo desglose que el checkout, y luego las dos líneas que el checkout todavía no puede tener: lo que ya se pagó, y lo que el hotel todavía va a cobrar. Todo lo que viene después en esta página deriva de esa decisión.
Confirmación, en wireframe. El desglose no se detiene en el pago, y los marcadores de moneda en la letra pequeña están ahí porque también tenía que ser cierto en cada mercado.
Proceso
Nueve pasos, repetidos en cada iteración
Esto nunca fue un proyecto con final. Es un ciclo que ha corrido varias veces, y cada pasada se apoyó en los pasos que el producto más necesitaba en ese momento. El benchmark es la excepción: se hizo a fondo una vez y después se consultó.
Mapear dónde aparece un precio
Un diagrama tosco de las interacciones que un viajero puede tener con un precio y lo que se sigue de cada una. No es un recuento completo de cada estado en que puede estar el embudo, ni iba a serlo nunca. Lo que compra son los casos límite que se pueden ver por adelantado en lugar de los que un desarrollador encuentra en un sprint, y un objeto compartido al que señalar cuando alguien pregunta si pensamos en varias habitaciones por varias noches en una moneda que el proveedor no usa.
Comparar ocho plataformas en siete países
Esta es la parte del proyecto que mostraría primero, y en la página original estaba plegada dentro de un panel colapsado hasta abajo. Empezó como una pregunta con una respuesta obvia y resultó no tener ninguna: ¿qué incluyen las otras plataformas en el precio por noche?
Responderla con honestidad significaba decidir contra quién comparar, dónde y bajo qué reserva. Entonces: Findhotel contra Expedia, Booking, Agoda, Skyscanner, TripAdvisor, Airbnb y Kayak, porque son con los que la empresa ya se medía. En los Países Bajos, Alemania, el Reino Unido, Australia, Bielorrusia, Indonesia e Israel, porque son los mercados donde nuestras propias reglas de visualización de precios ya diferían.
Los resultados comparables necesitan un control, así que cada búsqueda fue la misma búsqueda: Park Plaza Victoria en Ámsterdam, un adulto, una habitación, para la noche del 13 de octubre de 2020, un hotel elegido precisamente porque lleva tanto un impuesto municipal como una cuota de turismo. Las búsquedas se corrieron en septiembre, con un mes de anticipación, que es más o menos cuando alguien reserva una escapada urbana. Una segunda pasada pidió dos noches, del 13 al 15 de octubre, en los cinco mercados donde la primera había levantado una duda. Donde una plataforma no tenía ese hotel, se usó el equivalente más cercano y se anotó la sustitución.
¿La plataforma incluye el impuesto general en la tarifa por noche?
Había tres respuestas posibles: sí y desde los resultados de búsqueda en adelante, no y solo en el checkout, o nombra la tarifa base y el total juntos.
¿Incluye el impuesto local en la tarifa por noche?
Las mismas tres, preguntadas por separado, porque un impuesto municipal y un impuesto general sobre ventas los cobran personas distintas y las plataformas los tratan distinto.
Cincuenta y seis celdas, dos respuestas cada una. Se abre a tamaño completo, que es la única forma en que una tabla así de densa vale algo.
El hallazgo está en las dos filas con estrella. Airbnb y Expedia fueron las únicas plataformas que respondieron ambas preguntas igual en todos los mercados, y la respuesta que dieron no fue ni sí ni no: nombran la tarifa base y el total al mismo tiempo. Todos los demás, nosotros incluidos, elegimos un número y esperamos que fuera el correcto para ese país.
El tablero también registra lo que no funcionó. Las cifras de Skyscanner no cuadraban. TripAdvisor no parecía vender nada en Bielorrusia. Y Bielorrusia solo está en la lista porque Rusia era el mercado que yo quería y conseguir una VPN rusa resultó genuinamente difícil, que es el tipo de cosa que una sección de metodología suele omitir.
El segundo tablero: los paneles mismos, uno junto a otro. La fila de arriba es una habitación, la de abajo son varias, porque ahí es donde la mayoría deja de tener sentido.
Esos siete son la materia prima de la que se leyó la matriz. Cada uno es el panorama completo de un país capturado en una sola pasada, que es también por qué el estudio lleva fecha: así se veían estos sitios en septiembre de 2020, y varios han cambiado desde entonces.
Ideación, y luego acotar el alcance
Yo dirigí las sesiones de ideación, y el benchmark es lo que hizo que valieran la pena. Llevar a un equipo por lo que ocho competidores le hacen a la misma reserva es una forma más rápida de establecer qué es posible que cualquier cantidad de discusión, y mueve la conversación de opiniones sobre el precio a observaciones sobre los precios.
Después de cada sesión venía el alcance, con el product owner y el científico de datos. Dos preguntas, siempre en este orden: cómo se vería la respuesta correcta si nada estorbara, y cuál es la pieza más pequeña de ella que podríamos poner frente a tráfico real enseguida. La distancia entre esas dos respuestas es la hoja de ruta.
Un prototipo lo bastante barato para discutirlo
Los wireframes se volvieron un prototipo clicable, mantenido tosco a propósito. El público eran las partes interesadas y cualquiera en la empresa con algo en juego en el resultado, y una pantalla que se ve terminada invita a una conversación sobre qué tan terminada se ve. Una gris invita a una conversación sobre el precio.
Después pruebas de guerrilla, que aquí significa agarrar a quien esté disponible y verlo intentarlo. No sustituye a un estudio y nunca se ofreció como tal. Atrapa lo obvio, y genera las preguntas que vuelven al equipo como investigación de verdad: qué pasa cuando la moneda del viajero no es la moneda del proveedor, qué pasa con varias habitaciones, qué pasa cuando el cargo es mayor que la habitación.
El flujo entero en un teléfono, en bandas por etapa, en la forma en que se discutió por primera vez. Sigue más allá del checkout hasta los correos, la gestión de reservas y la cancelación, porque un precio que solo se desglosa mientras pagas no ha sido explicado. Cada línea extra cuesta además un scroll aquí, y vale la pena recordarlo cuando lleguen los resultados.
Convertirlo en tickets
Un diagrama de la ruta ideal y de los casos límite que importan, con cada rama cargando la pantalla que produce. De ese dibujo un product owner escribe tickets, y es la razón por la que un sprint se puede estimar siquiera. También es el artefacto al que vuelvo en el paso siete, cuando la pregunta es si lo construido hace lo que se acordó.
Entregarlo al front-end
Pantallas de alta fidelidad, dibujadas contra la guía de estilo y la librería de componentes de la empresa, de modo que un desarrollador ensambla piezas conocidas en lugar de interpretar una imagen. Las pantallas clave entraron a Zeplin en escritorio y móvil, que es de donde salen el padding, el color y el icono sin que nadie tenga que preguntar.
Revisar lo construido contra los escenarios
En cuanto los desarrolladores tenían algo sin lanzar, yo recorría a mano los escenarios acordados para ese sprint. Aquí es donde el mapa del paso uno y el diagrama del paso cinco se pagan solos, porque de lo contrario la respuesta a si todo quedó cubierto es el recuerdo que alguien tiene de una conversación.
Dos grabaciones de producción
Una vez que está en vivo, la pregunta cambia de si funciona a qué hace la gente con ello. FullStory graba sesiones reales y permite segmentar por comportamiento o por dónde está alguien, y todo lo que encontré digno de guardar, un error o una idea o un hábito que nadie había previsto, iba a un documento.
Dos de esas sesiones están aquí porque cada una muestra algo que una tasa de conversión no puede. Una es un viajero estadounidense en el lado B que va de la selección de habitación hasta el checkout. La otra es un viajero en Japón que abre el desglose del precio de una habitación, que es exactamente el gesto que este proyecto existió para volver valioso.
Estados Unidos, de la selección de habitación al checkout, en el lado B de la prueba
Japón, abrir el desglose del precio desde la página de selección de habitación
Hacer el cambio legible para los colegas
El último paso es el que decide si alguno de los otros viaja. El product owner y el científico de datos escribieron el relato legible; mi parte fue dibujar los dos lados uno contra otro para que alguien que nunca había estado en una sola reunión sobre esto pudiera hacer scroll una vez y ver qué se movió.
Los dos tableros de abajo recorren el mismo trayecto dos veces, selección de habitación a la izquierda y checkout a la derecha, con los puntos de decisión dibujados como rombos y el panel resultante bajo cada rama. Ponlos uno junto al otro y el cambio entero son tres cosas: el cargo recupera su nombre, lo que pagas ahora se separa de lo que pagas allá, y una frase dice quién lo cobra.
Conclusión
Lo que dijeron cinco semanas de tráfico
Conversión, para viajeros fuera de Estados Unidos, en una prueba de cinco semanas.
El efecto fue más marcado donde la gente ya espera que un precio mostrado contenga el impuesto. Lo que habíamos incorporado no era impuesto en absoluto: eran los cargos de hospedaje que estaban a su lado.
El tráfico de escritorio convirtió mejor. El tráfico móvil convirtió un poco peor, con el mismo cambio, en las mismas semanas.
Las reservas hechas con cerca de una semana de anticipación mejoraron. Las de último minuto quedaron un poco peor, que es el patrón que esperarías si leer toma un tiempo que alguien no tiene.
Ahora la parte menos cómoda. Apuntamos esto a viajeros estadounidenses que llegaban desde Google hotel ads, con el argumento de que eran el grupo más grande y valioso del sitio. La ganancia vino de todos los demás lados.
Eso no es un fracaso, pero es un resultado sobre el objetivo y no sobre el cambio, y merece leerse así. Un mercado donde el precio mostrado ya contiene el impuesto ha entrenado a sus viajeros para esperar que el número de la tarjeta sea el número que pagan. Rompe esa expectativa y la corrección vale mucho. Un mercado donde el impuesto se agrega al final ha entrenado la expectativa contraria, y ahí había menos que corregir.
La caída en móvil es la otra mitad de la misma frase. Cada cargo con su propia línea es una línea más, y un teléfono es donde una línea cuesta más. Nadie midió cuál de los dos efectos hacía el trabajo, así que lo que el resultado dice de verdad es que la claridad no es gratis en todas partes y que este proyecto nunca averiguó dónde deja de pagarse.
Lo que vino después
Para diciembre de 2020 el trabajo se había vuelto un documento y no una pantalla: un mapa de cómo debe expresarse un precio en cada etapa del embudo, de los resultados de búsqueda pasando por la selección de habitación y los detalles de la oferta hasta el checkout. Cuatro tableros, uno por etapa, cada uno la regla y no un ejemplo de ella.
Aquí también es donde se encuentran los dos proyectos de Findhotel en este sitio. Al fondo de ese tablero de checkout hay una elección entre pagar ahora y pagar en el hotel, y darle esa elección a alguien como se debe es un caso de estudio propio. Nombrar lo que cobra el hotel es lo que hizo posible ofrecerla.
Esos tableros son las reglas. Lo que la página original ofrecía a continuación era la cosa misma: un prototipo clicable de las tres lógicas de visualización de precios que el sitio corría a la vez, para que un lector pudiera probarlas en lugar de leer sobre ellas.
Pertenece aquí, al lado de ellos, y el espacio está reservado. El archivo vivía en Figma y esa dirección ya no resuelve, que es el destino común de todo lo que se guarda en el servidor de alguien más y la razón por la que nada más en esta página se carga desde uno. Vuelve en cuanto tenga un lugar propio donde vivir.
Lógica de visualización de precios, V4
Prototipo en proceso de rehospedaje
La versión interactiva de los cuatro tableros de arriba.
Aprendizajes
Hay una más, y es sobre de dónde salió esta página. Todo el benchmark que acabas de leer estaba, en la versión original de este caso de estudio, plegado dentro de un panel colapsado titulado the extra bits, debajo de la conclusión, con la admisión de que nada de eso era necesario. Era lo más útil de la página. El trabajo que llevó semanas suele quedar archivado como apéndice por quien lo hizo, porque lo recuerda como la parte anterior a cuando empezó el trabajo de verdad.