Mejorar la visualización de precios mediante la claridad

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 edge cases 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 un edge case muy específico.

Empezó como una pregunta con una respuesta compleja: ¿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.

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 opinión. 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 el desarrollo?", y "¿Cuál es la pieza más pequeña que podríamos desarrollar para poner en tráfico real?". La distancia entre esas dos respuestas formó el roadmap.

Los wireframes se volvieron un prototipo clicable, mantenido tosco a propósito. El público eran los stakeholders 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.

Un diagrama del happy path y de los edge cases que importan, con cada rama cargando la pantalla que produce. De ese dibujo un product owner escribe tickets. También es el artefacto al que vuelvo en el paso siete, cuando la pregunta es si lo construido hace lo que se acordó.

Pantallas de alta fidelidad, diseñadas con 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.

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.

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.

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 presentados como preguntas 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.