Creamos una aplicación de voz usando el ejemplo del Asistente de Google

Cada quinto residente de los Estados Unidos posee un altavoz inteligente, y esto es 47 millones de personas. El asistente puede crear un recordatorio, una lista de quehaceres, un reloj despertador, un temporizador, leer noticias, encender música, hacer podcasts, entregar pedidos, comprar entradas para el cine y llamar a un taxi. Estas son todas las "habilidades" o "habilidades" de los asistentes. También se llaman aplicaciones de voz. Se han desarrollado 70,000 aplicaciones para Alexa y Google Assistant para 2018.

En 2017, Starbucks lanzó la función de pedido de café en casa para Amazon Alexa. Además de aumentar los pedidos de entrega, todos los medios de comunicación posibles escribieron al respecto, creando un PR genial. A Starbucks le siguieron Uber, Domino's, MacDonald's e incluso Tide Laundry Detergent desarrolló su propia habilidad Alexa.

Al igual que Starbucks, la aplicación de voz realiza una o dos funciones: ordena café, activa una alarma o llama a un servicio de mensajería. Para diseñar algo similar, no es necesario ser una corporación intercontinental. La idea, diseño, prueba, desarrollo y lanzamiento es similar a etapas similares en el mundo del desarrollo móvil, pero con características para voz. Pavel Guay habló en detalle sobre el proceso: desde una idea hasta la publicación, con ejemplos de un juego real, con inserciones históricas y un análisis del mundo del desarrollo de la voz.



Sobre el orador : Pavel Gvay ( pavelgvay ) - diseña interfaces de voz en el estudio de desarrollo móvil KODE. El estudio está desarrollando aplicaciones móviles, por ejemplo, para Utair, Pobeda, RosEuroBank, BlueOrange Bank y Whiskas, pero KODE tiene una división que se ocupa de las aplicaciones de voz para Yandex.Alice y Google Assistant. Pavel participó en varios proyectos reales, intercambia experiencias con desarrolladores y diseñadores en este campo, incluidos los de EE. UU., Y habla en conferencias temáticas. Además, Pavel es el fundador de la startup tortu.io , una herramienta para diseñar aplicaciones de voz.

¿Qué es una aplicación de conversación?

En una aplicación de conversación, el canal de interacción con el usuario se construye a través de una conversación : oral, con un altavoz inteligente, o por escrito, por ejemplo, con el Asistente de Google. Además de la columna, el dispositivo de interacción puede ser una pantalla, por lo que las aplicaciones de conversación también son gráficas.

Es correcto hablar una aplicación hablada , no una aplicación de voz, pero este es un término establecido, y lo usaré también.

Las aplicaciones de voz tienen una ventaja importante sobre las móviles: no necesitan ser descargadas e instaladas. Es suficiente saber el nombre, y el asistente comenzará todo por sí mismo.

Esto se debe a que no hay nada que descargar, tanto el reconocimiento de voz como la lógica empresarial, toda la aplicación vive en la nube. Esta es una gran ventaja sobre las aplicaciones móviles.

Un poco de historia

La historia de los asistentes de voz comenzó con Interactive Voice Response , un sistema interactivo de respuestas de voz grabadas. Quizás nadie escuchó este término, pero todos se encontraron cuando llamaron al soporte técnico y escucharon al robot: “Presione 1 para acceder al menú principal. Haga clic en 2 para obtener más información ”: este es el sistema IVR . En parte, IVR puede llamarse la primera generación de aplicaciones de voz. Aunque ya son parte de la historia, pueden enseñarnos algo.

La mayoría de las personas, cuando interactúan con el sistema IVR, intentan contactar al operador. Esto se debe a una mala experiencia de usuario cuando la interacción se basa en equipos duros, lo cual es un inconveniente.

Esto nos lleva a la regla básica de una buena aplicación conversacional.

Una buena aplicación de conversación interactúa con el usuario no a través de comandos estrictos, sino a través de una conversación viva y natural, similar a la comunicación entre personas.

Una conversación con la aplicación debería ser más como llamar a una pizzería para pedir un pedido que comunicarse con un bot de chat por equipos. No será posible lograr la misma flexibilidad que en una conversación entre personas, pero hablar con la aplicación en un lenguaje cómodo y natural es bastante.

Esta es también la ventaja de las aplicaciones de voz sobre gráficos: no es necesario aprender a usar . Mi abuela no sabe cómo ir a sitios o pedir pizza a través de la aplicación, pero puede llamar a la entrega a través de la columna. Deberíamos usar esta ventaja y adaptarnos a la forma en que las personas hablan, y no enseñarles a hablar con nuestra aplicación.

Pasemos de los sistemas IVR al presente, a los asistentes virtuales.

Asistentes virtuales

El mundo de las voces gira en torno a asistentes virtuales: Google Assistant , Amazon Alexa y Alice .

Todo está organizado casi como en el mundo móvil, solo que en lugar de las plataformas iOS y Android hay Alice, Google Assistant y Alexa, en lugar de aplicaciones gráficas: voz, con sus propios nombres o nombres, y cada asistente tiene su propia tienda de aplicaciones de voz. Nuevamente, decir "aplicación" está mal, porque cada plataforma tiene su propio término: Alice tiene "habilidades", Alexa tiene "habilidades" y Google tiene "acciones".

Para comenzar la habilidad, le pregunto al asistente: "¡Alexa, dile a Starbucks que quiero café!", Alexa encontrará la aplicación de cafetería en su tienda y le dará la conversación. Luego, la conversación no va entre Alex y el usuario, sino entre el usuario y la aplicación . Muchos están confundidos y piensan que el asistente continúa hablando con ellos, aunque la aplicación tiene una voz diferente.

Así es como se ven las tiendas de aplicaciones. La interfaz se asemeja a la App Store y Google Play.

Pasos de desarrollo de aplicaciones conversacionales

Para el usuario, la aplicación no tiene una parte gráfica: todo parece un conjunto de diálogo. Exteriormente, puede parecer que la aplicación es algo simple, es simple crearla, pero no lo es. Los pasos de desarrollo son los mismos que para las aplicaciones móviles.

• Diseño. En el caso de la voz, no es la representación de pantallas, sino la elaboración de diálogos.
• El desarrollo se divide en dos partes: el desarrollo de un sistema de comprensión del habla y la escritura de la lógica.
• Pruebas
• Publicación

Las dos primeras etapas son específicas, ya que las aplicaciones son conversacionales, y las dos últimas son estándar.

Pasaremos por cada una de las etapas con el juego Adivina el precio , que se lanza bajo el Asistente de Google. La mecánica es simple: la aplicación muestra al usuario una tarjeta con los productos y debe adivinar el precio.

Comencemos la inmersión desde la primera etapa: decidimos la idea, realizamos análisis, nos dimos cuenta de que el usuario tenía una necesidad y procedimos a crear una aplicación de voz.

Diseño

El objetivo principal es diseñar la interacción entre el usuario y la aplicación. En el mundo móvil, esta etapa se llama diseño. Si el diseñador de aplicaciones gráficas dibuja mapas de pantallas, botones, formas y selecciona colores, entonces el diseñador de VUI elabora el diálogo entre el usuario y la aplicación: prescribe varias ramas del diálogo, piensa en tenedores y escenarios secundarios, selecciona opciones de frase.

El diseño se lleva a cabo en tres etapas.

• Ejemplos de diálogos.
• Dibujar un diagrama de flujo.
• Elaboración de listas de avisos.

Ejemplos de diálogo

Lo primero que debe hacer es comprender cómo funcionará la aplicación. La comprensión y la visión deberán transmitirse a todos los demás, especialmente si usted es una empresa de outsourcing y debe explicarle al cliente lo que finalmente recibirá.

Una herramienta poderosa para ayudar son ejemplos de diálogos: una conversación entre un usuario y una aplicación sobre roles , como en una obra de teatro.

Un ejemplo de diálogo para nuestro juego.



La aplicación saluda, le dice al usuario sobre las reglas, ofrece jugar y, si la persona está de acuerdo, muestra una tarjeta con los productos para que el usuario adivine el precio.

El script ayuda a comprender rápidamente cómo funcionará la aplicación, lo que puede hacer, pero, además, los ejemplos de diálogos ayudan a eliminar el error principal en el mundo de las interfaces de voz: trabajar en scripts incorrectos .

Hay una regla simple: si no puedes imaginar cómo estás hablando el guión con otra persona, entonces no deberías trabajar en ello.

La voz y los gráficos son significativamente diferentes, y no todo lo que funciona en interfaces gráficas funciona bien en la voz. Casi todas las aplicaciones móviles tienen un registro, pero no puedo imaginar cómo puede registrarse por voz. Cómo dictar una contraseña para una columna inteligente: "Una letra mayúscula, una letra pequeña, es como un dólar ...", y todo esto en voz alta. ¿Y si no estoy solo, sino en el trabajo? Este es un ejemplo de un escenario de error. Si comienza a desarrollar un script con un error, habrá problemas con él: no entenderá cómo ejecutarlo, los usuarios no entenderán cómo usarlo.

Ejemplos de diálogos ayudarán a encontrar momentos similares. Para encontrar errores en los escenarios, escriba el diálogo, seleccione un colega, siéntese enfrente y desempeñe los roles: usted es el usuario, el colega es la aplicación. Después de leer la función de diálogo, quedará claro si la aplicación suena o no, y si será conveniente para el usuario.

Tal problema aparecerá constantemente. Si tiene un desarrollo interno, entonces surgirá la tentación: "Ya tenemos un sitio web, ¡simplemente conviértalo en voz y todo estará bien!" O el cliente vendrá y dirá: “Aquí hay una aplicación móvil. ¡Haz lo mismo, solo con la voz! Pero no puedes hacer eso. Usted, como especialista, debe encontrar rápidamente escenarios en los que no debería trabajar y explicarle al cliente por qué. Ejemplos de diálogos ayudarán aquí.

Absolutamente cualquier editor de texto al que esté acostumbrado es adecuado para prescribir diálogos. Lo principal es escribir el texto y leerlo por roles.

Diagrama de flujo

Los ejemplos de diálogo son una herramienta poderosa, rápida y barata, pero describen solo un desarrollo lineal de eventos, y las conversaciones son siempre no lineales . Por ejemplo, en nuestro juego "Adivina el precio", el usuario puede responder la pregunta correcta o incorrectamente: esta es la primera bifurcación del conjunto de las que ocurrirá más adelante.

Para no confundirse en todas las ramas del diálogo de su aplicación, haga un diagrama de bloques: visualización del diálogo. Consta de solo dos elementos:

• Paso de diálogo en nombre del usuario.
• Paso de diálogo en nombre de la aplicación.
  

El diagrama de flujo es un mapa de nuestra aplicación, pero con una propiedad desagradable: crece fuertemente, se vuelve ilegible y visualmente incomprensible. Aquí, por ejemplo, hay una captura de pantalla con una parte de un diagrama de flujo de un escenario en el que el usuario adivina el precio, con varios tenedores.



Varios tenedores no son el límite, puede haber decenas o cientos de ellos. Nos hicimos preguntas: “¿Qué sucede si una persona responde correctamente? Y si no? ¿Qué pasa si los intentos terminan? ¿Qué pasa si las mercancías se agotan? ¿Y si adivina el precio con seguridad? ¿Qué pasa si Internet se cae en este paso u otro? Como resultado, creamos un enorme esquema ilegible.

No estamos solos en esto. Hablé con un diseñador de EE. UU. Que estaba trabajando en un proyecto serio. El proyecto tenía IVR, un banco y habilidades al mismo tiempo, y todo esto infló un diagrama de bloques de hasta 600 hojas. Nadie entendió el esquema hasta el final, y cuando la diseñadora lo vio, simplemente se horrorizó.

Tengo consejos sobre cómo prevenir esto. El esquema siempre crecerá, pero nunca intente construir un diagrama de bloques grande para toda la aplicación ; será engorroso y nadie, excepto usted, lo comprenderá. Vaya desde el lado opuesto y divida el diagrama en partes lógicas : un escenario separado de adivinación de precios, un escenario separado de ayuda. Divide estos escenarios en subescenarios según sea necesario. El resultado no es un gran mapa con conexiones incomprensibles, sino muchos circuitos pequeños, legibles y bien conectados en los que todos se sienten cómodos para navegar.

Para diagramas de bloques, cualquier herramienta es adecuada. Solía ​​usar RealtimeBoard , y también hay Draw.io e incluso XMind . Como resultado, desarrollé el mío, porque es más conveniente. En la imagen solo se presenta. Esta herramienta también admite sub-scripting.

listas de avisos

El último artefacto que formaremos en la etapa de diseño. La lista de solicitudes es una lista de todas las frases posibles que la aplicación puede pronunciar.

Hay una sutileza. La conversación con la aplicación debe ser flexible y similar a una conversación con una persona. Esto significa no solo la capacidad de atravesar diferentes ramas, lo que hicimos en la etapa del diagrama de flujo, sino el sonido de la conversación en su conjunto. Una persona nunca responderá con la misma frase si hace la misma pregunta. La respuesta siempre será parafraseada y sonará de alguna manera diferente. La aplicación debe hacer lo mismo, por lo que para cada paso del diálogo en nombre de la aplicación, escriba no una opción de respuesta, sino al menos cinco.



Según las hojas de instrucciones, hay otra cosa importante. La comunicación no solo debe ser viva y flexible, sino también coherente en términos de estilo de discurso y el sentimiento general de interacción del usuario con su aplicación. Para esto, los diseñadores usan una técnica excelente: crear un personaje . Cuando llamo a mi amigo, no lo veo, pero inconscientemente me imagino a mi interlocutor. El usuario tiene lo mismo cuando se comunica con un altavoz inteligente. Esto se llama pareidalia .

En la etapa de hojas de solicitud, crea un personaje en nombre de quién hablará la aplicación. Sus usuarios asociarán la marca y la aplicación con el personaje; puede ser una persona real o ficticia. Trabaje para él apariencia, biografía, personaje y humor, pero si no hay tiempo, simplemente traiga todas sus frases en las hojas de instrucciones a un solo estilo. Si comenzó a ponerse en contacto con el usuario en "Usted", no se ponga en contacto con otros lugares en "Usted". Si tiene un estilo informal de comunicación, manténgalo en todas partes.

Por lo general, las hojas de cálculo de Excel o Google se utilizan para crear hojas de solicitud, pero con ellas hay grandes pérdidas temporales en el trabajo de rutina. El diagrama de flujo y la tableta con las frases no están conectados entre sí, los cambios deben transferirse manualmente, lo que se traduce en una rutina constante y larga.

No uso Excel, pero mi herramienta, porque en él todas las frases están escritas directamente en el diagrama de flujo, se asignan al paso de diálogo. Esto elimina la rutina.

Al diseñar, elaboramos cada escenario: escribimos un ejemplo de diálogo, buscamos ramificaciones laterales, errores, lo cubrimos con un diagrama de flujo y luego trabajamos en el estilo del discurso y las frases.

Parece que ahora todo está listo y puede asignar la tarea a los desarrolladores y acceder al código, pero aún queda una etapa más importante: las pruebas. Tenemos que asegurarnos de que, como diseñadores, hagamos todo correctamente, que la aplicación funcione como queremos, que todas las frases tengan el mismo estilo, que hayamos cubierto todas las ramas laterales y procesado todos los errores.

Prueba

Las pruebas en esta etapa temprana son especialmente importantes para las aplicaciones de voz. En el mundo de las interfaces gráficas, el usuario está limitado por lo que el diseñador dibujó: no irá más allá de la pantalla, no encontrará un botón que no existe y solo hará clic en lo que está ...

En el mundo de las voces, esto no es así: el usuario es libre de decir cualquier cosa y usted no sabe cómo comenzará a trabajar con su aplicación hasta que la vea. Es mejor hacer esto en una etapa temprana de diseño y prepararse para lo inesperado hasta que el costoso desarrollo haya comenzado.



Las aplicaciones se prueban utilizando la metodología Wizard of Oz . Se utiliza en aplicaciones gráficas, pero con menos frecuencia, y en voz es imprescindible. Este es un método cuando el usuario interactúa con el sistema, suponiendo que existe y funciona por sí solo, pero usted controla todo el proceso.

Las pruebas se realizan utilizando prototipos interactivos. Por lo general, el diseñador tiene que pedirles a los desarrolladores que creen un prototipo, pero personalmente uso mi herramienta, porque todo se hace con un solo clic y no hay necesidad de esperar a nadie. También necesitamos un usuario. Llamamos a una persona que no está involucrada en el desarrollo, que no sabe nada sobre la aplicación e, idealmente, está incluida en su público objetivo. Invitas a una persona, explicas qué tipo de aplicación es, cómo usarla, plantarla en una habitación, encender un prototipo interactivo y el usuario comienza a hablar con él. El prototipo no reconoce el habla y escucha lo que dice la persona y elige la opción de respuesta mediante la cual la aplicación responde a cada frase.

Si el usuario no ve la pantalla, le parece que la aplicación funciona por sí sola, pero usted controla el proceso. Esto está probando al Mago de Oz. Con él, no solo escuchará cómo suena la aplicación, sino que también verá cómo las personas la usan. Le garantizo que encontrará muchos escenarios descubiertos.

Cuando probé el juego, llamé a mi amigo. Comenzó a adivinar el precio y dijo que algún tipo de ungüento valía "cinco chozas". No esperaba tal palabra, pensé que habría opciones de 500 rublos, mil rublos, y no una "choza de cinco" o "segar". Esto es un poco revelado durante las pruebas. La gente usa la aplicación de manera diferente a lo que imaginas, y las pruebas revelan tales bagatelas y escenarios inoperantes.

Pruebe mucho y durante mucho tiempo antes del desarrollo, hasta que esté seguro de que la aplicación funciona y los usuarios interactúen con ella como espera.

En esta etapa, finaliza la fase de diseño y tenemos a mano ejemplos de diálogos, un diagrama de bloques es una descripción lógica de la aplicación, y las listas de avisos son lo que dice la aplicación. Le daremos todo esto a los desarrolladores. Antes de contarte cómo los desarrolladores crean aplicaciones, compartiré consejos de diseño.

Consejos

Use el lenguaje de marcado SSML , como HTML, solo para voz. SSML le permite pausar, establecer el nivel de empatía, estrés, registrar qué leer y deletrear.



El discurso etiquetado suena mucho mejor que el robot, y cuanto mejor suena la aplicación, más agradable es de usar. Así que use SSML, no es tan complicado.

Piense en los momentos en que los usuarios recurren a su aplicación para obtener ayuda. Para la voz, esto es especialmente importante. Una persona puede hablar con un orador solo en una habitación, o puede viajar en autobús y hablar con un teléfono inteligente. Estos son dos escenarios de comportamiento fundamentalmente diferentes para una aplicación de voz. Tuvimos una situación similar con una aplicación bancaria. Había un script en la aplicación cuando el usuario recibe información sobre la cuenta, y esta es información privada. Pensé: si una persona está hablando en casa, entonces todo está bien, pero si viaja en un autobús y la aplicación comienza a expresar el saldo de la tarjeta en voz alta, será feo.

Pensando en esos momentos, puede determinar que si el usuario está hablando con el teléfono inteligente, incluso con una voz, es mejor no leer la información privada en voz alta, sino mostrarla en la pantalla.

Utilice diseño multimodal.

Este es un diseño para diferentes superficies y plataformas. Los dispositivos de voz son muy diferentes en textura. En el mundo móvil, los dispositivos difieren solo en plataforma y tamaño de pantalla, factor de forma. Con una voz, todo es diferente. Por ejemplo, la columna no tiene una pantalla, solo una voz. El teléfono inteligente tiene una pantalla y puede tocarlo con el dedo. El televisor tiene una pantalla enorme, pero es inútil tocarlo. Piense en cómo funcionará su aplicación en cada una de estas superficies.

Por ejemplo, un usuario realizó una compra y queremos mostrar el cheque. Leer el cheque en voz alta es una mala idea, porque hay mucha información y nadie la recordará, ya que la información de voz se percibe como difícil y difícil.



, , , , , . , .

. , — , . , , .

. , Amazon Alexa, Google Assistant.



, . - , .

• — intent , — , : , , webhook , . - webhook, , API.
• .

Dialogflow , , , .

— Natural Language Understanding — NLU.

Dialogflow

Dialogflow, , , . Dialogflow : — Google Assistant, -, Amazon Alexa Telegram . — API. , .

Dialogflow.

• Agent — , , .
• Intents — .
• Entities — .
• Contexts — , .

, — Intents.

Intents

, , . . , : « », «, ?», « — » - . , Intent , , .

10 . , Dialogflow , 10 , , . , , .

Intent . Dialogflow , , webhook. , — : , .

«» — . , Google Assistant , , , . Google Assistant , .

Entities

Intent , - . — , , — Entities . , , , , . : .



. « », . , — . , :

— ?
— !

Dialogflow re-prompt — , , . . - : « , ...»

— Entities. Dialogflow — , , . , , , , . Dialogflow — . ^ , , , . , , . : «», Dialogflow , «»

Context

: context — , . , : « ?» , . , . , : « », . Google , — .



context — « — » , . Intent context , -, . context . : , 5 , .

context — : , . , Intent, context , Intent. .



webhook. Dialogflow , JS. Google Assistant webhook — , 5 , fallback. , — 1,5 3 .

, webhook , QA, .

, , .

, . . , .

:

• . ., . , « », , .
• , , .

Google Assistant , — «, Google, ...». , , : «, Google, Uber» — , . , : «, Google, Uber !» , .

, . , — . , « » , « » . , «» «» Google Assistant. , , .

, . Google Assistant , , .

.

• Alpha — 20 .
• Beta — 200 .
• Production- — store. Production, . Google , , . , . , , .
  

, , , — .

. , , — , , .

. , Dialogflow :

• — .
• — , , , .

, . - : «4 ». «» , «» — .



, , .

. , . , , - .

-
- .
Slack- Amazon Alexa
Slack- Google Assistant
Google Assistant
Amazon Alexa
«Designing VUI» Cathy Pearl
«VUX best practices, Voicebot»
Medium
Google Assistant
Amazon Alexa
.
,

: Twitter Linkedin , Medium .

AppsConf 2019 se llevará a cabo en el centro de Moscú, en Infospace, los días 22 y 23 de abril. Prometemos aún más utilidades de desarrollo móvil que el año pasado, así que reserve un boleto o deje una solicitud de informe .

Para mantenerse al tanto de las noticias y anuncios de informes, suscríbase a nuestro boletín y al canal de YouTube para el desarrollo móvil .

¡Solo AppsConf, solo hardcore!