Nous créons une application vocale en utilisant l'exemple de Google Assistant

Un résident sur cinq aux États-Unis possède une colonne intelligente, ce qui représente 47 millions de personnes. L'assistant peut créer un rappel, une liste de tâches, un réveil, une minuterie, lire des nouvelles, activer la musique, un podcast, commander la livraison, acheter des billets de cinéma et appeler un taxi. Ce sont toutes des «compétences» ou «compétences» des assistants. Ils sont également appelés applications vocales. 70000 applications ont été développées pour Alexa et Google Assistant pour 2018.

En 2017, Starbucks a lancé la fonction de commande de café à domicile pour Amazon Alexa. En plus d'augmenter les commandes de livraison, tous les médias possibles ont écrit à ce sujet, créant ainsi un bon RP. Starbucks a été suivi par Uber, Domino's, MacDonald's et même Tide Laundry Detergent a développé sa propre compétence Alexa.

Comme Starbucks, l'application vocale a une ou deux fonctions: commander du café, régler une alarme ou appeler un service de messagerie. Pour concevoir quelque chose de similaire, il n'est pas nécessaire d'être une société intercontinentale. L'idée, la conception, les tests, le développement et la sortie sont similaires à des étapes similaires dans le monde du développement mobile, mais avec des fonctionnalités pour la voix. Pavel Guay a parlé en détail du processus: d'une idée à la publication, avec des exemples d'un vrai jeu, avec des encarts historiques et une analyse du monde du développement de la voix.



À propos de l'orateur : Pavel Gvay ( pavelgvay ) - conçoit des interfaces vocales dans le studio de développement mobile KODE. Le studio développe des applications mobiles, par exemple, pour Utair, Pobeda, RosEuroBank, BlueOrange Bank et Whiskas, mais KODE a une division qui s'occupe des applications vocales pour Yandex.Alice et Google Assistant. Pavel a participé à plusieurs projets réels, a échangé des expériences avec des développeurs et des designers dans ce domaine, y compris des États-Unis, et a pris la parole lors de conférences thématiques. De plus, Pavel est le fondateur de la startup tortu.io , un outil de conception d'applications vocales.

Qu'est-ce qu'une application de conversation

Dans une application de conversation, le canal d'interaction avec l'utilisateur se construit à travers une conversation : orale - avec un haut-parleur intelligent, ou écrite, par exemple, avec Google Assistant. En plus de la colonne, le dispositif d'interaction peut être un écran, les applications conversationnelles sont donc également graphiques.

Il est correct de parler une application parlée , pas une application vocale, mais c'est un terme établi et je vais l'utiliser aussi.

Les applications vocales ont un avantage important sur les applications mobiles: elles n'ont pas besoin d'être téléchargées et installées. Il suffit de connaître le nom et l'assistant va tout démarrer lui-même.

En effet, il n'y a rien à télécharger - à la fois la reconnaissance vocale et la logique métier - l'ensemble de l'application vit dans le cloud. C'est un énorme avantage par rapport aux applications mobiles.

Un peu d'histoire

L'histoire des assistants vocaux a commencé avec Interactive Voice Response , un système interactif de réponses vocales enregistrées. Peut-être que personne n'a entendu ce terme, mais tout le monde est venu quand ils ont appelé le support technique et entendu le robot: «Appuyez sur 1 pour accéder au menu principal. Cliquez sur 2 pour en savoir plus »- c'est le système IVR . En partie, l'IVR peut être appelé la première génération d'applications vocales. Bien qu'ils fassent déjà partie de l'histoire, ils peuvent nous apprendre quelque chose.

La plupart des gens, lorsqu'ils interagissent avec le système IVR, essaient de contacter l'opérateur. Cela est dû à une mauvaise UX lorsque l'interaction est basée sur des équipes dures, ce qui est tout simplement gênant.

Cela nous amène à la règle de base d'une bonne application conversationnelle.

Une bonne application de conversation interagit avec l'utilisateur non pas par le biais de commandes strictes, mais par le biais d'une conversation vivante et naturelle, semblable à la communication entre les personnes.

Une conversation avec l'application devrait ressembler davantage à appeler une pizzeria pour une commande qu'à communiquer avec un chat par des équipes. Il ne sera pas possible d'obtenir la même flexibilité que dans une conversation entre personnes, mais parler avec l'application dans un langage confortable et naturel est tout à fait.

C'est aussi l'avantage des applications de voix sur graphique: pas besoin d'apprendre à utiliser . Ma grand-mère ne sait pas comment se rendre sur les sites ou commander des pizzas via l'application, mais elle peut appeler la livraison via la colonne. Nous devons utiliser cet avantage et nous adapter à la façon dont les gens parlent, et ne pas leur apprendre à parler avec notre application.

Passons des systèmes IVR à nos jours - aux assistants virtuels.

Assistants virtuels

Le monde de la voix tourne autour des assistants virtuels: Google Assistant , Amazon Alexa et Alice .

Tout est organisé presque comme dans le monde mobile, mais au lieu des plates-formes iOS et Android, il y a Alice, Google Assistant et Alexa, au lieu des applications graphiques - voix, avec leurs propres noms ou noms, et chaque assistant a son propre magasin d'applications vocales. Encore une fois, dire «application» est faux, car chaque plate-forme a son propre terme: Alice a «compétences», Alexa a «compétences» et Google a «actions».

Pour exécuter la compétence, je demande à l'assistant: "Alexa, dis à Starbucks que je veux du café!", Alexa trouvera l'application de café dans son magasin et lui donnera la conversation. Ensuite, la conversation ne va pas entre Alex et l'utilisateur, mais entre l'utilisateur et l'application . Beaucoup sont confus et pensent que l'assistant continue de parler avec eux, bien que l'application ait une voix différente.

Voici à quoi ressemblent les boutiques d'applications. L'interface ressemble à l'App Store et à Google Play.

Étapes de développement d'applications conversationnelles

Pour l'utilisateur, l'application n'a pas de partie graphique - tout ressemble à un ensemble de dialogues. Extérieurement, il peut sembler que l'application est une chose simple, il est simple de la créer, mais ce n'est pas le cas. Les étapes de développement sont les mêmes que pour les applications mobiles.

• Conception. Dans le cas de la voix, ce n'est pas le rendu d'écrans, mais l'élaboration de dialogues.
• Le développement est divisé en deux parties: le développement d'un système de compréhension de la parole et l'écriture de la logique.
• Test.
• Publication

Les deux premières étapes sont spécifiques, car les applications sont conversationnelles et les deux dernières sont standard.

Nous passerons par chacune des étapes en utilisant le jeu Devinez le prix , qui est lancé sous l'Assistant Google. La mécanique est simple: l'application montre à l'utilisateur une carte avec la marchandise, et il doit deviner le prix.

Commençons la plongée à partir de la première étape: nous avons décidé de l'idée, réalisé des analyses, réalisé que l'utilisateur avait un besoin et procédé à la création d'une application vocale.

La conception

L'objectif principal est de concevoir l'interaction entre l'utilisateur et l'application. Dans le monde mobile, cette étape est appelée design. Si le concepteur d'applications graphiques dessine des cartes d'écrans, de boutons, de formes et sélectionne des couleurs, le concepteur VUI élabore le dialogue entre l'utilisateur et l'application: prescrit diverses branches du dialogue, pense aux fourches et aux scénarios latéraux, sélectionne des options de phrase.

La conception s'effectue en trois étapes.

• Exemples de dialogues.
• Dessiner un organigramme.
• Etablissement de listes d'invites.

Exemples de dialogue

La première chose à faire est de comprendre le fonctionnement de l'application. La compréhension et la vision devront être diffusées à tout le monde, surtout si vous êtes une entreprise d'externalisation, et vous devez expliquer au client ce qu'il recevra finalement.

Un outil puissant pour aider sont des exemples de dialogues: une conversation entre un utilisateur et une application sur les rôles , comme dans une pièce.

Un exemple de dialogue pour notre jeu.



L'application salue, informe l'utilisateur des règles, propose de jouer et, si la personne est d'accord, montre une carte avec la marchandise pour que l'utilisateur devine le prix.

Le script permet de comprendre rapidement comment l'application fonctionnera, ce qu'elle peut faire, mais, en outre, des exemples de dialogues aident à éliminer l'erreur principale dans le monde des interfaces vocales - travailler sur des scripts incorrects .

Il existe une règle simple: si vous ne pouvez pas imaginer comment vous parlez du script avec une autre personne, alors vous ne devriez pas y travailler.

La voix et les graphiques sont sensiblement différents, et tout ce qui fonctionne sur les interfaces graphiques ne fonctionne pas bien sur la voix. Presque toutes les applications mobiles ont un enregistrement, mais je ne peux pas imaginer comment vous pouvez vous inscrire par la voix? Comment dicter un mot de passe à une colonne intelligente: "Une majuscule, une petite lettre, c'est comme un dollar ..." - et tout cela à voix haute. Et si je ne suis pas seul, mais au travail? Ceci est un exemple de scénario d'erreur. Si vous commencez à développer un script avec une erreur, il y aura des problèmes: vous ne comprendrez pas comment l'exécuter, les utilisateurs ne comprendront pas comment l'utiliser.

Des exemples de dialogues aideront à trouver des moments similaires. Pour trouver des erreurs dans les scénarios, notez la boîte de dialogue, sélectionnez un collègue, asseyez-vous en face et jouez les rôles: vous êtes l'utilisateur, le collègue est l'application. Après avoir lu le rôle de dialogue, il deviendra clair si l'application sonne ou non, et si cela sera pratique pour l'utilisateur.

Un tel problème apparaîtra constamment. Si vous avez un développement en interne, alors la tentation se fera sentir: "Nous avons déjà un site Web, convertissons-le simplement en voix et tout ira bien!" Ou le client viendra et dira: «Voici une application mobile. Faites de même, juste par la voix! " Mais vous ne pouvez pas faire ça. En tant que spécialiste, vous devez trouver rapidement des scénarios sur lesquels vous ne devriez pas travailler et expliquer pourquoi au client. Des exemples de dialogues vous seront utiles ici.

Absolument n'importe quel éditeur de texte auquel vous êtes habitué convient pour prescrire des boîtes de dialogue. L'essentiel est d'écrire le texte et de le lire par rôles.

Organigramme

Les exemples de dialogue sont un outil puissant, rapide et bon marché, mais ils ne décrivent qu'un développement linéaire des événements, et les conversations sont toujours non linéaires . Par exemple, dans notre jeu «Devinez le prix», l'utilisateur peut répondre correctement ou incorrectement à la question - c'est la première fourchette de l'ensemble de celles qui se produiront plus tard.

Afin de ne pas vous confondre dans toutes les branches du dialogue de votre application, faites un schéma fonctionnel - visualisation du dialogue. Il se compose de seulement deux éléments:

• Étape de dialogue au nom de l'utilisateur.
• Étape de dialogue au nom de l'application.
  

L'organigramme est une carte de notre application, mais avec une propriété désagréable - elle croît fortement, devient illisible et incompréhensible visuellement. Voici, par exemple, une capture d'écran avec une partie d'un organigramme d'un scénario où l'utilisateur devine le prix, avec plusieurs fourchettes.



Plusieurs fourches ne sont pas la limite, il peut y en avoir des dizaines ou des centaines. Nous nous sommes posé des questions: «Que se passe-t-il si une personne répond correctement? Et sinon? Que se passe-t-il si les tentatives se terminent? Et si les marchandises s'épuisent? Et s'il devine le prix à coup sûr? Et si Internet tombe en panne à cette étape ou à une autre? » En conséquence, nous avons créé un énorme schéma illisible.

Nous ne sommes pas seuls dans ce domaine. J'ai parlé à un designer américain qui travaillait sur un projet sérieux. Le projet avait en même temps un système RVI, une banque et des compétences, et tout cela a gonflé un schéma fonctionnel de jusqu'à 600 feuilles. Personne n'a compris le schéma jusqu'à la fin, et lorsque la créatrice l'a vu, elle était tout simplement horrifiée.

J'ai des conseils sur la façon d'éviter cela. Le schéma se développera toujours, mais n'essayez jamais de construire un grand diagramme pour toute l'application - ce sera lourd, et personne sauf vous ne le comprendra. Aller de l'opposé et diviser le diagramme en parties logiques : un scénario distinct de devinettes de prix, un scénario séparé d'aide. Décomposez ces scénarios en sous-scénarios si nécessaire. Le résultat n'est pas une grande carte avec des connexions incompréhensibles, mais de nombreux petits circuits lisibles et bien connectés dans lesquels tout le monde est à l'aise de naviguer.

Pour les schémas fonctionnels, n'importe quel outil convient. J'avais l'habitude d'utiliser RealtimeBoard , et il y a aussi Draw.io et même XMind . En conséquence, j'ai développé le mien, car il est juste plus pratique. Dans l'image juste, il est présenté. Cet outil prend également en charge les sous-scripts.

listes d'invites

Le dernier artefact que nous formerons au stade de la conception. La liste d'invites est une liste de toutes les phrases possibles que l'application peut prononcer.

Il y a une subtilité. La conversation avec l'application doit être flexible et similaire à une conversation avec une personne. Cela signifie non seulement la possibilité de passer par différentes branches, ce que nous avons fait au stade de l'organigramme, mais le son de la conversation dans son ensemble. Une personne ne répondra jamais avec la même phrase si vous posez la même question. La réponse sera toujours paraphrasée et sonnera différemment. L'application doit faire de même, donc pour chaque étape du dialogue au nom de l'application, n'écrivez pas une option de réponse, mais au moins cinq.



Selon les feuilles d'invite, il y a une autre chose importante. La communication doit être non seulement vivante et flexible, mais également cohérente en termes de style de parole et de sentiment général d'interaction de l'utilisateur avec votre application. Pour cela, les concepteurs utilisent une excellente technique - créer un personnage . Quand j'appelle mon ami, je ne le vois pas, mais j'imagine inconsciemment mon interlocuteur. L'utilisateur a la même chose lorsqu'il communique avec un haut-parleur intelligent. C'est ce qu'on appelle la paréidalie .

À l'étape des feuilles d'invite, vous créez un personnage au nom duquel l'application parlera. Vos utilisateurs associeront la marque et l'application au personnage - il peut s'agir d'une personne réelle ou fictive. Travaillez pour lui l'apparence, la biographie, le caractère et l'humour, mais s'il n'y a pas de temps, il vous suffit de regrouper toutes vos phrases dans les feuilles d'invite dans un seul style. Si vous avez commencé à contacter l'utilisateur sur "Vous", alors ne contactez pas d'autres endroits sur "Vous". Si vous avez un style de communication informel, respectez-le partout.

Habituellement, les feuilles de calcul Excel ou Google sont utilisées pour créer des feuilles d'invite, mais avec elles, il y a d'énormes pertes temporaires dans le travail de routine. L'organigramme et la tablette avec les phrases ne sont en aucun cas liés les uns aux autres, tout changement doit être transféré manuellement, ce qui se traduit par une routine constante et longue.

Je n'utilise pas Excel, mais mon outil, car toutes les phrases y sont écrites directement dans l'organigramme, elles sont affectées à l'étape de dialogue. Cela élimine la routine.

Lors de la conception, nous élaborons chaque scénario: nous écrivons un exemple de dialogue, trouvons des branches latérales, des erreurs, couvrons cela avec un organigramme, puis travaillons sur le style de parole et les phrases.

Il semble que maintenant tout soit prêt et que vous puissiez confier la tâche aux développeurs et accéder au code, mais il reste une étape plus importante: les tests. Nous devons nous assurer qu'en tant que concepteurs, nous avons tout fait correctement, que l'application fonctionnera comme nous le voulons, que toutes les phrases sont dans le même style, que nous avons couvert toutes les branches latérales et traité toutes les erreurs.

Test

Les tests à ce stade précoce sont particulièrement importants pour les applications vocales. Dans le monde des interfaces graphiques, l'utilisateur est limité par ce que le designer a dessiné: il n'ira pas au-delà de l'écran, ne trouvera pas de bouton qui n'existe pas, et ne fera que cliquer sur ce qui est ...

Dans le monde des voix, ce n'est pas le cas: l'utilisateur est libre de dire n'importe quoi, et vous ne savez pas comment il va commencer à travailler avec votre application jusqu'à ce que vous le voyiez. Il est préférable de le faire à un stade précoce de la conception et de se préparer à l'inattendu jusqu'à ce qu'un développement coûteux ait commencé.



Les applications sont testées en utilisant la méthodologie Wizard of Oz . Il est utilisé dans les applications graphiques, mais moins fréquemment, et en voix c'est un must have. Il s'agit d'une méthode lorsque l'utilisateur interagit avec le système, en supposant qu'il existe et fonctionne de manière autonome, mais que vous contrôlez l'ensemble du processus.

Les tests sont effectués à l'aide de prototypes interactifs. Habituellement, le concepteur doit demander aux développeurs de créer un prototype, mais personnellement j'utilise mon outil, car tout se fait en un clic et il n'y a pas besoin d'attendre qui que ce soit. Nous avons également besoin d'un utilisateur. Nous appelons une personne qui n'est pas impliquée dans le développement, ne sait rien de l'application et, idéalement, est incluse dans votre public cible. Vous invitez une personne, expliquez de quel type d'application il s'agit, comment l'utiliser, plantez-la dans une pièce, allumez un prototype interactif et l'utilisateur commence à lui parler. Le prototype ne reconnaît pas la parole, vous entendez ce que la personne dit et choisissez l'option de réponse par laquelle l'application répond à chaque phrase.

Si l'utilisateur ne voit pas l'écran, il lui semble que l'application fonctionne d'elle-même, mais vous contrôlez le processus. Ceci teste Wizard of Oz. Avec lui, vous entendrez non seulement le son de l'application, mais vous verrez également comment les gens l'utilisent. Je vous garantis que vous trouverez de nombreux scénarios non couverts.

Quand j'ai testé le jeu, j'ai appelé mon ami. Il a commencé à deviner le prix et a dit qu'une sorte de pommade valait "cinq huttes". Je ne m'attendais pas à un tel mot, je pensais qu'il y aurait des options de 500 roubles, mille roubles, et non pas un «cinq cabanes» ou une «tonte». C'est une bagatelle qui a été révélée lors des tests. Les gens utilisent l'application différemment de ce que vous imaginez, et les tests révèlent de telles bagatelles et des scénarios inopérants.

Testez beaucoup et longtemps avant le développement, jusqu'à ce que vous soyez sûr que l'application fonctionne et que les utilisateurs interagissent avec elle comme prévu.

À ce stade, la phase de conception se termine et nous avons des exemples de boîtes de dialogue sous la main, un schéma de principe est une description logique de l'application et des listes d'invites sont ce que dit l'application. Nous donnerons tout cela aux développeurs. Avant de vous dire comment les développeurs créent des applications, je vais partager des conseils de conception.

Astuces

Utilisez le langage de balisage SSML - comme HTML, pour la parole uniquement. SSML vous permet de faire une pause, de définir le niveau d'empathie, de stress, d'enregistrer ce que vous voulez lire et épeler.



La parole étiquetée sonne bien mieux que robotique, et plus l'application est bonne, plus elle est agréable à utiliser. Utilisez donc SSML - ce n'est pas si compliqué.

Pensez aux moments où les utilisateurs se tournent vers votre application pour obtenir de l'aide. Pour la voix, c'est particulièrement important. Une personne peut parler à un haut-parleur seule dans une pièce, ou elle peut monter dans un bus et parler à un smartphone. Il s'agit de deux scénarios de comportement fondamentalement différents pour une application vocale. Nous avons eu une situation similaire avec une application bancaire. Il y avait un script dans l'application lorsque l'utilisateur reçoit des informations sur le compte, et il s'agit d'informations privées. J'ai pensé - si une personne parle à la maison, alors tout va bien, mais s'il voyage dans un bus et que l'application commence à exprimer le solde de la carte à haute voix - ce sera moche.

En pensant à de tels moments, vous pouvez déterminer que si l'utilisateur parle au smartphone, même avec une voix, il vaut mieux ne pas lire les informations privées à haute voix, mais les afficher à l'écran.

Utilisez une conception multimodale.

Ceci est une conception pour différentes surfaces et plates-formes. Les appareils vocaux ont une texture très différente. Dans le monde mobile, les appareils ne diffèrent que par la plate-forme et la taille de l'écran - facteur de forme. Avec une voix, tout est différent. Par exemple, la colonne n'a pas d'écran du tout - seulement une voix. Le smartphone dispose d'un écran et vous pouvez le toucher avec votre doigt. Le téléviseur a un écran géant, mais il est inutile de le toucher. Pensez au fonctionnement de votre application sur chacune de ces surfaces.

Par exemple, un utilisateur a effectué un achat et nous voulons montrer le chèque. — , , .



, , , , , . , .

. , — , . , , .

. , 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, .

Publication

, , .

, . . , .

:

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

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 tiendra au centre de Moscou, dans Infospace les 22 et 23 avril. Nous promettons encore plus d'utilitaires de développement mobile que l'année dernière, alors réservez un billet ou laissez une demande de rapport .

Pour vous tenir au courant des nouvelles et des annonces de rapports, abonnez-vous à notre newsletter et à la chaîne YouTube pour le développement mobile .

Seulement AppsConf, seulement hardcore!