“Alexa, abre LATAM”

Voy a contarte cómo creamos la primera skill de Alexa para una aerolínea en Sudamérica.

Alguien me dijo una vez que el mundo era una interfaz. En esos años no lograba entender el porqué de ese pensamiento, hasta que vi este video sobre como un equipo del MIT creo un producto digital donde la interfaz es el cuerpo.

Cuando pensamos que cualquier cosa que nos rodea se puede convertir en una interfaz, nuestros sentidos, imaginación y habilidades se abren para diseñar más allá de lo que estamos acostumbrados en el día a día. A eso nos enfrentamos cuando nos propusieron iniciar el diseño y desarrollo de la skill de LATAM Airlines para Alexa.

Desde el punto de vista de UX, los desafíos eran infinitos: no era simplemente diseñar una interfaz “que no se ve”. Tuvimos la oportunidad de mejorar la experiencia a otro nivel, más allá de ver u oír una interfaz; nuestro propósito no era hacer la mejor skill, sino que disfrutaras la mejor skill, que sintieras, que te despertara todos los sentidos.

Quisimos hacerte reír, que nos amaras, que tu mente viajara por nuestros destinos, mientras decidieras dónde pasar tus próximas vacaciones. Nos propusimos que te olvidaras por un momento del robot, pero al mismo tiempo, quisimos ser útiles para ti.

Una interfaz que no se ve, pero que se escucha

Alexa es un asistente de voz, donde la interacción es la conversación. Obviamente, para crear esta interfaz definimos un usuario y diseñamos para él. Utilizamos todos los datos e investigaciones que los equipos de UX en LATAM Airlines recolectaron a lo largo de meses.

El primer desafío fue considerar los flujos de interacción como conversacionales. Mirando la forma en cómo abordamos el proceso, fue muy parecido a diseñar una partitura de interacción: usamos la misma metodología para crear sinergia entre los equipos de UX, desarrollo y negocio.

Creamos cuatro flujos, que ya están en producción:

• Estado de vuelo. El objetivo de esta funcionalidad es que le preguntes a la skill de LATAM en Alexa si tu vuelo está a tiempo.
• Búsqueda de destino. La idea es inspirarte, para que decidas sobre tu próximo viaje.
• Trivia. Es un juego para conocer un poco sobre la industria aeronáutica, de manera divertida.
• El cuarto flujo es…¡una sorpresa! Tendrás que descubrirlo :).

Con cada flujo creado, ideamos un particular storytelling para cada uno de ellos: una pequeña variación de este artefacto, adaptado para mantener consistencia entre todos los flujos sin perder el foco en la interacción.

En la imagen a continuación, se muestra cómo cada color representa una interacción, la manera en cómo ésta se ejecuta y el diálogo, dependiendo de cada caso.

Ideamos un storytelling considerando la emoción como elemento principal.

No queríamos una skill que fuera sólo útil, queríamos que las personas sonrieran, se sintieran cómodas. Fue un logro ver, en los testeos con usuarios reales, cómo la gente le agradecía al robot o le sonreía para despedirse. No habíamos considerado que las personas se despidieran diciendo “chao Alexa! gracias!”.

Para el storytelling se definieron diferentes momentos de conversación, cada uno de ellos identificados por una emoción positiva o negativa. Por ejemplo:

• Momento: saludo — emoción positiva.
• Momento: hate — emoción negativa

Para cada momento creamos diferentes respuestas, dependiendo de la emoción. Si Alexa no contesta lo que quieres oír en un determinado momento, entonces te generamos una emoción negativa, lo que contrarrestamos con determinadas respuestas.

Si Alexa te contesta siempre lo mismo (por ejemplo “lo siento no entendí”), en vez de aminorar la frustración, la aumenta, por lo tanto, tuvimos que añadir otras posibilidades a un mismo momento.

Basados en esa misma interacción contruimos el storytelling acompañado de diferentes guiños:

• Expresiones como “yahooo”, “qué delicia la playa”.
• Expresiones auditivas como sonido del mar.
• Expresiones visuales (imagenes relacionadas a la conversación).

Mientras estructurábamos el storytelling un miembro del equipo pensó que, dada la forma en cómo estábamos construyendo el relato, podrías creer que nuestra skill te respondería otras preguntas, más allá del estado del vuelo o dónde ir de vacaciones. Entonces pensamos ¿qué pasa si alguien pregunta a Alexa LATAM “quiero ir a la luna”?… y bueno, en honor a mejorar la experiencia ideamos algunas respuestas para nuestros clientes más creativos. Esto fue muy divertido y enriquecedor, nos ayudó todo el equipo de UX de LATAM Airlines, en una actividad de sólo 15 minutos.

Interfaces visuales como elementos secundarios de apoyo

Para apoyar nuestro hermoso relato, utilizamos interfaces visuales para el Eco Show 5.

La oportunidad y limitaciones del propio dispositivo fueron un desafío. Nos tuvimos que plantear y replantear en varias ocasiones que, para este caso, la interfaz visual no era la experiencia principal sino que es sólo un apoyo. No voy a entrar en detalles sobre la guía visual que tiene Alexa, creo que es mucho más interesante ahondar en las decisiones que fuimos tomando sobre las jerarquías, porque en este proyecto, fue muy drástico el “lo mostramos o no”.

Y aunque nos cansamos de decir que la interfaz es un elemento secundario, nos dimos cuenta de lo complejo que es crear una consistencia y una buena experiencia entre dos tipos de interacciones (auditivo y visual).

Iteramos, creamos y deshicimos a partir de un grupo de wireframes y tuvimos una evolución importante. Hubo feedback en varias instancias dentro del equipo y también en testeos con usuarios reales.

Primera versión de Estado de vuelo

La primera feature en la que trabajamos fue “Estado de vuelo”. En el inicio de las iteraciones y feedbacks sobre los diseños de interfaz visual que estábamos proponiendo, integrantes del equipo de UX LATAM Airlines nos alertaron sobre algo relevante: el estado del vuelo se perdía en el texto principal.

El diseño de las card con la información del vuelo partió con información que suponíamos era básica:

• Estado del vuelo.
• Número de vuelo.
• Origen — destino.
• Hora de inicio y llegada, con los códigos IATA correspondientes.
• Tiempo de vuelo.
• Terminadas de llegada y salida.

En cuanto al diseño visual comenzamos aplicando la principal paleta de colores corporativa.

Segunda versión de Estado de vuelo

Mejoramos la jerarquía del estado en esta versión, pero comenzamos a lidiar con otros tipos de decisiones: “¿qué necesita ver nuestros usuarios en primer lugar?”.

A diferencia de la primera versión, decidimos comenzar a simplificar la información y el diseño visual, para llevar la atención de nuestros clientes a la información más importante: el estado del vuelo.

Quitamos los códigos IATA.

Tercera versión de Estado de vuelo

Parecía que lo estábamos logrando, pero nuevamente, y gracias al constante feedback, nos hicieron ver que estábamos entregando demasiada información en un espacio muy limitado.

Aunque jugamos con las jerarquías, la paleta, los contraste, para poder incluir toda la información, no fue suficiente, la pequeña interfaz visual seguía recargada de información.

Cuarta versión y final

Para llegar a este punto — debo decir que simplifiqué mucho el relato — ¡fue mucho trabajo!: iteraciones con todo el equipo de UX de LATAM Airlines, testeos con usuarios reales, datos sobre el uso de nuestras aplicaciones, entre otros muchos datos.

Finalmente, privilegiamos la información que necesita nuestro cliente en un contexto de uso específico; el resto del contenido fue descartado. Dejamos un diseño limpio, con menos información, pero muy concreto y específico.

Éste es uno de los flujos completos

Contexto de uso no sólo como parte de la experiencia sino como factor determinante

Probablemente esta es una historia conocida: “diseña para el contexto de uso”. Parece muy obvio, es parte de nuestro trabajo diario, estamos acostumbrados a pensar en el contexto de uso cuando diseñamos para un móvil, para el computador de escritorio, etc.

Estamos familiarizados en la creación de interfaces en un contexto de uso donde nuestro cliente está interactuando con una pantalla.

Con Alexa, el contexto de uso considera aspectos como: un usuario que se mueve por su casa, que está cocinando, lavando, haciendo otras actividades en paralelo.

Todo esto implica que Alexa debe escuchar a nuestro cliente y él debe escuchar al dispositivo, el usuario necesita poder leer lo que aparece en la diminuta pantalla y, como si fuera poco, debe tener la opción de decidir cuándo tocar la pantalla para interactuar (la pantalla del Eco Show es táctil).

Entonces ¿en qué momento de nuestros journeys nuestro cliente interactúa con nuestra skill? La respuesta es más sencilla de lo que parece, siempre está en su casa, sólo que puede estar haciendo otras tareas en paralelo, por lo tanto, estamos luchando con varias atenciones, las tareas diarias, la televisión, música, incluso el móvil.

A esto agreguemos otro desafío: el contexto son los testeos con usuarios reales y, aunque tenemos conciencia que es difícil testear en un contexto real de uso, éste fue uno de los aspectos más difíciles.

¿Qué enseñanzas nos dejó?

• Siempre es necesario testear con usuarios reales, ésta no es la excepción.
• Hay que establecer tareas como en testeos de interfaces visuales. Vimos un intento de hacerlo sin tareas definidas y la verdad es que el resultado difiere mucho al que se espera de un testeo.
• Inventamos un nuevo concepto “el testeo guerrilla mago de OZ”. No testeen en producción para validar un flujo, un humano puede simular ser Alexa y a través de un “dispositivo fake” puede interactuar con el usuario a través de un computador. El cliente no tiene cómo enterarse que es fake si se hace bien :).
• Las pruebas en producción son eficaces sólo si el flujo funciona de manera óptima. Es necesario probarlo antes, de lo contrario pueden hacer perder el tiempo a muchas personas.
• Los testeos deben tener un objetivo claro. Es importante que exista un objetivo por flujo o por feature. A veces, el objetivo no es terminar el flujo, sino validar que los aspectos específicos de cada interacción funcionan. Por ejemplo: ¿qué funciona mejor? ¿quiero saber el estado de mi vuelo o quiero saber el estado de un vuelo?
• Para validar un flujo con pantallas es recomendable primero testear sin mockups. Si el flujo se valida sin pantallas, entonces seguir con el testeo completo (voz más mockups).

Finalmente los dejo con “Alexa, abre LATAM”.

Para probar el flujo completo, si tienen un dispositivo Echo de Alexa, pueden descargar la skill, pero deben hacerlo desde una cuenta de Brasil.

Disfrútenlo y estaremos encantados de recibir más feedback para mejorar :)

Créditos: Javier Arocha (UX designer) y Romina Tagle (UX writer).