Seleccionar página

Mi cuñao

Proyecto Voice interface

Fecha:
Enero – Junio 2019.

Equipo:
Product Owner
Desarrolladores
Lingüistas
Conversacional UX designer

Una idea que nace desde la directiva de Sngular, buscando generar espacios, donde crear productos digitales para el público en general, en esta oportunidad se desea construir y validar una plataforma de servicio, utilizando como punto de contacto la interfaz de voz.

El reto por la parte técnica era desarrollar en Amazon Lex, una plataforma desconocida por el equipo, además de construir un DB que se adapte a nuestras necesidades. En diseño debíamos adaptar los conocimiento que teníamos en chatbot a asistentes de voz, y por último existía la posibilidad de haber rotaciones dentro del equipo, por el modelo de negocio de la empresa consultoría.

Mi rol.
Participando en todas las fases del proceso de diseño, inclusive en la gestión del proyecto

Manos a la obra.

Para unificar la visión del producto, crear hipótesis y definir otras series de aspectos claves del proyecto se realiza un inception, que converge entre otras cosas definiendo un MVP, con las siguientes funcionalidades: Ofrecerte un consejo, Ofertas de productos, Viajes en base a presupuesto, Recomendación de restaurantes.

Al plantear estas funcionalidades surgen muchas preguntas, ¿Nos hemos equivocado eligiendo estas funcionalidades y no otras? ¿Vamos a ofrecer respuestas útiles para los usuario? ¿Nos van a dar acceso a sus datos? ¿Hay funcionalidades que se utilizaran más que otras?.

Forma parte de las hipótesis que surgieron en la fase de divergencia. Para nosotros era clave medir las valoraciones, tanto positivas como negativas, los usuarios únicos que ingresan a la skill’s, su recurrencia de uso y número de intenciones que lanzan durante el mismo, básicamente KPI’s que nos ayuden a determinar el éxito del proyecto.

Y los stakeholders, ¿Qué piensan?.

Para ellos el proyecto persigue dos grandes objetivos, primero a nivel empresarial querían generar espacios para crear productos digitales de principio a fin, con nuevas tecnologías y formas de trabajo novedosas. A nivel de producto construir algo que aporte valor, facilitando la toma de decisiones de los usuarios, publicando una fase beta antes del verano.

Vale, pero… ¿Cómo monetizamos?.

Los modelo de negocio que utilizan las Skill’s para monetizar son escasos, inclusive en mercados más desarrollados como EEUU no tienen muchas formas de monetizar, estas son algunas de ellas:

  1. Desarrollando Skill’s elegibles que sean las más usadas en España.
  2. Desarrollando Skill’s disponibles en EE.UU, Reino Unido, Alemania y Japón.
  3. Desarrollar servicios de pago de aplicaciones a terceros, para flujos de compra.
  4. Engagement que deriva a contenido premium.
  5. Por publicidad.

Ok, pero ¿Quien es nuestro publico objetivo?

Realizamos una encuesta a más de setenta personas, conociendo cómo influyen los Smart Speaker en su vida diaria, la frecuencia de uso y otros factores. Al finalizar las encuestas, nos dimos cuenta que el reto era aún mayor, ya que el mercado español se muestra receptivo para ayudarle a tomar ciertas decisiones, pero aún están en la fase de descubrimiento.

» Nos toca pivotar de público a los early adopter»

Marina Valle, 32 años.

Soltera y vive de alquiler en un piso de Malasaña (Madrid). Trabaja como diseñadora, por lo que tiene flexibilidad en su localización.

Conoce a Marina

Paco López, 46 años.

Tiene dos hijos (Gabi 5 años y Bea 2 años) y vive en un adosado en Alcobendas. Tiene soluciones Smart Home en su hogar.

Hablemos del Voice system persona.

El tono de voz es un rasgo muy característico de nuestra personalidad, podemos transmitir alegría, rabia, miedo y tristeza. También sabemos que en ocasiones solemos utilizar expresiones que llegan a definir nuestra personalidad; Por ello se desarrolló un VUI canvas, que sirve como marco, para perfilar la personalidad de cualquier producto de voz. A fin de profundizar más sobre el canvas, pincha aquí.

Al haber definido el system persona, comenzamos la arquitectura de la conversación, realización “diagramas de flujo” que se fueron ajustando según las necesidades que tenía desarrollo para entenderlo y los lingüistas para crear los diálogos, realizando los ítems de chollos y viajes, establecidos en fases previas. Hay varios aspecto claves a la hora de realizar la arquitectura de la conversación:
 

  1. Es importante construir o al menos validar con desarrollo los flujos, ya que se pueden tomar decisiones muy complicadas de desarrollar o simplemente en nuestro caso, no había forma de obtener los datos.
  2. Identificar cuando hablaba el sistema y cuando el usuario es clave, ya que creando los diálogos en oportunidades era confuso, no sabías en qué punto estabas de la conversación.
  3. Identificar cuando el sistema no tenía más información que ofrecer, con rombos de decisión para el usuario y para el sistema.
  4. El diagrama de flujo es una herramienta que ayuda a mantener el equipo alineado, con respeto a las decisiones que afectan tanto a diseño como desarrollo.

Test friend and family

Al finalizar los diálogos de chollos y viajes realizamos un test con siete personas, permitiendo evaluar el trabajo realizado hasta el momento, planteando las siguientes hipótesis:

  1. Percibir si los usuarios finalizan los flujos.
  2. Evaluar la claridad del mensaje y la propuesta de valor.
  3. Entender si las funcionalidades aportan valor.
  4. Determinar posibles carencias de las funcionalidades.

Los smart speaker tienen varios tipos de voces masculinas y femeninas, siendo la última la más desarrollada por ello se decidió utilizarla para el test con el Amazon Polly, estas son algunas de las conclusiones:

 

  1. Los ítems necesitan categorías para facilitar su uso.
  2. Comprobamos que los usuarios nombran los 3 parámetros de forma directa.
  3. La voz femenina causa rechazo por el nombre masculino del proyecto Mi cuñao.
  4. Sería útil en el ítems de viaje incluir una propuesta de itinerario.
  5. Algunos usuarios no les aporta valor el ítems de viajes, no deja clara algunas cosas.
  6. Refinar el mensaje de la propuesta de valor, más breve y concisa.

«Cambio de planes sobre el ítems de segunda mano»

Tras realizar el test nos dimos cuenta que le aporta más valor al usuario un ítems de itinerarios que de segunda mano, por ello se decide cambiar. Continuamos trabajando, de cara a refinar los flujos para el Wizard of Oz se extrajo del teatro una técnica llamada lectura de guión, ejercicio que permitió evidenciar las carencias en los diálogos y la arquitectura.

.

Wizard of Oz

Después de hacer la captación y las encuestas, que nos permitieron definir el tipo de flujo (viaje, chollo, itinerarios y restaurantes) que hacía cada uno, obtuvimos doce usuarios.

Para el test se tomó la decisión de prescindir de Amazon Poly y que uno de nuestros compañeros hiciese de skill’s, ya que anterior el tema de la voz fue un punto no favorable.

Conclusiones generales
 

  1. Dejar claro cuando acaba el flujo, evitando dejar el micrófono abierto.
  2. Cuando necesitemos información del usuario, la intervención debe terminar en pregunta.
  3. Dejar los datos relevantes y las llamadas de acción al final del mensaje.
  4. No mezclar información diferentes en el mismo mensaje, tiende a confundir.
  5. Cuando se elige una propuesta debemos confirmarla en el siguiente mensaje, repitiendo y ampliando la información relacionada.
Últimos detalles.

En la fase de Research además de aprender de nuestros usuarios, también pudimos encontrar nuevas ideas a explorar, como la recomendación de charlas y eventos por ciudad, reservar un restaurante u ofrecer algún consejo para viajar a un destino específico, ideas que quedan en el tintero para ampliar a futuras funcionalidades.

Centrándonos en la construcción del MVP; el equipo de diseño se dedicó a refinar los diálogos utilizados para cada Ítem, aplicando los criterios de Usabilidad aprendidos en la fase Testing, mientras el resto desarrolla los ítems restantes y se crea una LP para la captación de Beta Tester.

Una vez terminado Mi cuñao, llega el momento de presentarnos en la reunión anual de análisis de resultados de la empresa donde hicimos un resumen de todo lo que habíamos construido en estos meses de trabajo, la verdad fue todo un éxito.

Conclusiones Generales.

En general los objetivos de la empresa se cumplieron, porque el lanzamiento del propio producto era un reto. Luego se crearon artefactos internos válidos para el desarrollo de proyectos de interfaz de voz y se crearon sinergías entre desarrollo y diseño para la creación de productos de innovación.

A nivel de producto se tomaron ciertas decisiones basadas en las evidencias de la fase beta, funciono de una manera diferente a la que pensábamos, teniendo que pivotar a una skill’s de recomendaciones de restaurantes en las zona de Madrid.

Web y App Kschool