Rédiger les dialogues
Notre série d’articles concernant la conception de l’expérience vocale touche à sa fin ! Après avoir discuté de comment définir la personnalité de votre assistant vocal et de comment choisir une voix, je vous parle aujourd’hui de comment concevoir des dialogues.
PS : cet article aborde la conception d’un assistant vocal du point de vue UX uniquement.
Quels sont vos cas d’usages ?
Mais qu’est-ce qu’un cas d’usage ?
Lorsque vos utilisateurs se servent de votre assistant, ils ont des besoins différents en fonction du contexte. Vous devez donc vous demander : « que vont rechercher mes utilisateurs et quels vont être leurs besoins ? »
Reprendre vos personas ou encore votre Brand Spint vous aidera à définir ces cas d’usages : qui sont vos utilisateurs ? quels sont leurs besoins et que doit faire votre assistant vocal ?… Des questions que vous vous êtes déjà posées dans les étapes précédentes et auxquelles vous avez déjà répondu. Vous êtes rodés !
Il ne vous reste donc plus qu’à lister les différents cas d’usages. En voici un exemple :
→ Cas d’usage : Demander la météo
- Service : Assistant vocal OK Google qui a pour objectif d’aider l’utilisateur dans toutes ses demandes, notamment une recherche internet
- Contexte : Marie, 25 ans, est souvent pressée le matin et ne pense jamais à regarder la météo la veille. Elle a donc peu de temps et elle aimerait pouvoir faire faire ses recherches à son assistant en même temps qu’elle finit de s’habiller
- Demande possible : « OK Google, donne moi la météo d’aujourd’hui »
- Réponse que l’assistant doit apporter : « Bonjour Marie, il fait ensoleillé ce matin avec une température de 20°. Il fera cependant nuageux dans l’après-midi avec une température qui descend à 17°
Ne listez que les cas d’usages les plus utiles ! Évitez à tout prix d’ajouter des cas marginaux. Avant d’étendre la portée de la conception pour gérer de potentiels nouveaux scénarios, examinez attentivement l’impact → si c’est un cas rare ou qui ne concernera que très peu d’utilisateurs, il vaut parfois simplement mieux prévoir un message d’erreur et inciter l’utilisateur à formuler autrement ou lui dire explicitement que sa demande n’est pas réalisable
Jouez l’assistant vocal – Action !
Alors oui, vous avez bien lu ! A cette étape de la conception, le mieux est de jouer et faire comme si vous étiez votre assistant vocal.
En réalité, vous serez 2 : trouvez un partenaire pour dialoguer. L’un joue l’utilisateur, l’autre joue l’assistant vocal. Si vraiment vous n’avez pas de partenaire, il va falloir faire appel à la schizophrénie et jouer les 2 rôles en même temps… c’est possible, mais plus compliqué et vous ne pourrez pas bénéficier de l’avis d’une 2ème personne.
Mais partons du principe que vous êtes 2 :
- Mettez vous en face à face, choisissez qui aura quel rôle
- Reprenez la liste de vos cas d’usages : la personne qui joue le rôle des utilisateurs devra se mettre dans la peau de vos personas
- Commencez par un cas d’usage et jouez : l’utilisateur pose sa question, la personne qui joue l’assistant vocal répond comme elle pense que l’assistant devrait répondre, et le dialogue continue ainsi.
- Ecrivez la conversation : ce sera votre première version du dialogue
- Text to speech : pour mieux se projeter, il est possible de passer les dialogues écrits dans un outil de TTS (text to speech). L’écrit ne sonne pas comme le parler. Le meilleur moyen de vérifier si un dialogue est pertinent ou non est, soit de le mimer, soit de le tester avec un outil de TTS.
Pour aller plus loin On vous conseille de bencher comment les autres assistants vocaux déjà existants se comportent dans des situations similaires à votre assistant vocal, ça vous fera économiser du temps et ça évite de réinventer la roue ! Un autre point intéressant est de créer un formulaire pour demander à vos futurs utilisateurs comment ils formuleraient une même demande.
Poser le flow et humaniser
Bon là comme ça on vous l’accorde : ça peut faire peur. En réalité, cette partie consiste à poser les dialogues que vous aurez créé dans l’étape précédente, puis les humaniser.
1. Identifiez les patterns
Un pattern est un modèle, une structure que vous pouvez répliquer pour ne pas réinventer la roue à chaque fois. Poser un modèle simplifie aussi la vie de vos utilisateurs. Ils comprendront plus facilement la façon dont fonctionne votre interface vocale.
Ici, on veut surtout vous parler du wake up pattern (réveil), du listening pattern (écoute) et du processing pattern (traitement) qui sont les 3 patterns obligatoires à prendre en compte lors de la conception d’un assistant vocal.
⏰ Wake up pattern (réveil) : vous devez définir comment votre assistant vocal s’active à chaque fois. Par exemple :
- L’utilisateur cite le nom d’appel
- L’assistant allume sa LED
- Un overlay s’affiche sur l’interface sur laquelle l’utilisateur est (Google Assistant affiche un overlay sur le smartphone lorsqu’il est appelé par exemple)
👂 Listening pattern (écoute) : vous devez définir la manière dont votre assistant fait comprendre à l’utilisateur qu’il l’écoute. Par exemple :
- Suite au réveil, l’assistant fait clignoter sa LED avec un son spécifique en amont pour indiquer qu’il écoute l’utilisateur + l’overlay indique l’écoute
- L’utilisateur formule sa demande
- L’assistant arrête sa LED, émet un son pour indiquer la fin d’écoute + l’overlay indique une fin d’écoute
🤔 Processing pattern (traitement) : ce dernier pattern sert à définir comment votre assistant indiquera à votre utilisateur qu’il est en train de processer l’information. Par exemple :
- La LED clignote désormais de façon à indiquer à l’utilisateur que l’assistant process + l’overlay indique un chargement
Vous l’avez remarqué, on a parlé de LED, overlay et son… Bon, c’est un sujet à part entière et ça sera sûrement l’objet d’un prochain article, mais oui, l’expérience utilisateur passe aussi par le visuel et le son. Par son, on entend les virgules sonores qui permettront à vos assistants d’être bien identifié par les utilisateurs, ou simplement des sons indicateurs qui permettent à l’utilisateur de comprendre ce qu’il se passe : son d’écoute, son de fin d’écoute, son de validation, son d’erreur, etc. Pas évoqué dans cet article, mais c’est (peut-être) pour bientôt !
2. Posez sous forme de flowchart
Une fois les dialogues rédigés par cas d’usages et les pattern identifiés, il faut faire le flowchart, plus correctement appelé flow conversationnel dans le cas de la conception d’une Voice User Interface (VUI).
Chez La Haute Société, on a posé le flux des dialogues sur Miro (voir image juste au-dessus) parce que visuellement c’est hyper pratique et ça nous permet ensuite de tester rapidement et simplement.
On l’a déjà dit, sur ce sujet nous étions uniquement en support sur la partie UX, mais lorsqu’il y a du développement le plus simple c’est de travailler sur Dialogflow. On vous laissera aller y jeter un oeil si besoin.
Ce qu’on vous conseille :
- Faites une board de flow par cas d’usage
- Précisez le contexte
- Posez vos blocs de patterns avec le discours de l’utilisateur que ce soit pour réveiller l’assistant ou lui faire sa demande
- Indiquez les différentes réponses / actions de l’assistant selon s’il a compris la demande, s’il a besoin de précision ou s’il rencontre une erreur.
Vous avez un projet de VUI et vous souhaitez plus d’infos ? N’hésitez pas à nous contacter, on se fera une joie de discuter avec vous !
3. Humanisez
Alors oui, il est possible d’humaniser encore un peu plus votre assistant vocal.
Google l’explique très bien dans ces guidelines mais vous pouvez ajouter ce qu’on appelle des composants conversationnels. Ce sont toutes ces petites choses qui vont composer les dialogues, comme les remerciements ou les questions / affirmations, et qu’ils le rendront d’autant plus humain et agréable. On vous en cite quelques-uns très importants, mais on vous incite fortement à aller jeter un oeil aux guidelines Google :
- 🙏 Remerciements Les remerciements sont des mots et des phrases comme «D’accord», «Bien sûr», «Merci» et «J’ai compris». Utilisez-les pour confirmer l’acceptation, la confirmation, le refus, la correction et avant de changer de sujet. Cela rassure l’utilisateur qu’il a été entendu et que l’assistant suit la conversation.
- 👍 Confirmations Les confirmations donnent aux utilisateurs des commentaires sur la façon dont leur contribution a été comprise. Non seulement cela permet aux utilisateurs de corriger immédiatement les erreurs, mais cela les rassure également sur ce qu’a compris l’assistant.
- 🛑 Erreurs Lorsque les utilisateurs ne sont pas en mesure de terminer leurs tâches, il est peu probable qu’ils parlent à votre assistant à l’avenir. Une erreur mal gérée peut l’emporter sur des dizaines d’interactions réussies. Mais avec une bonne gestion des erreurs, l’utilisateur ne saura même pas qu’une erreur s’est produite.
- 🤔 Questions L’un des moyens les plus efficaces pour amener l’utilisateur à poursuivre la conversation (par exemple, faire un choix) est de poser une question. Lorsque l’appel à l’action n’est pas clair, l’utilisateur ne sait pas quand ni comment répondre.
… Et bien d’autres !
Testez !
Je sais ce que vous vous dites : « ça commence à faire beaucoup de tests là ». Mais est-ce qu’on vous a déjà dit qu’à La Haute Société on aime placer l’expérience utilisateur au cœur du projet ? Certainement, mais on ne le dira jamais assez (je pense) 🤷♀️
Du coup, pour tester vos dialogues, vous avez 3 possibilités :
→ La méthode « all in » / Déconseillé. En résumé : vous terminez votre assistant, vous le programmez, vous en sortez un prototype que vous testez. En gros : c’est un énorme coup de poker parce que si ça rate, il faut tout recommencer depuis le début.
👍 L’avantage – avec un prototype poussé il n’y a pas photo, vous pouvez difficilement faire plus proche du produit final et l’utilisateur ne pourra que mieux se projeter.
👎 L’inconvénient – c’est que vous êtes passés en développement et que si jamais vos tests remontent des modifications à apporter (et c’est sur, ne vous leurrez pas), il faudra revenir en arrière et tout recommencer. Vous risquez de perdre du temps et de l’argent. À côté de ça, le risque lors de vos tests c’est que vos utilisateurs n’ont pas que les dialogues à écouter, mais ont tout le contexte autour : voix de l’assistant, virgules sonores, etc. alors que vous souhaitez uniquement des retours sur vos dialogues.
→ Le Magicien d’Oz, ou l’appel à un ami / Conseillé
En plus d’être le meilleur moyen de placer l’humain au centre de votre projet, c’est aussi un moyen rapide de tester les dialogues que vous avez créé sans avoir à passer en développement, à prototyper ou coder pour le moment. Comment faire ?
- Prenez une personne non familière avec le projet qui se rapproche d’un persona défini pour tester le dialogue.
- Donnez un cas d’usage à la personne : elle doit formuler sa demande à l’assistant (vous)
- Vous (l’assistant) devez répondre en fonction du flow défini dans les étapes précédentes. Si à un moment la personne sort du flow, improvisez et notez le vous pour vous rappeler les améliorations à apporter à vos dialogues
👍 L’avantage – c’est rapide, simple à mettre en place et vous avez des retours en direct. Important aussi : l’utilisateur se concentre uniquement sur ce que vous voulez tester – les dialogues.
👎 L’inconvénient – c’est moins contextualisé qu’avec un proto
En conclusion…
À l’issue de cette 3è étape :
- Vous connaissez vos cas d’usages
- Vous avez les dialogues pour chaque cas d’usage
- Vous connaissez les différents composants conversationnels pour humaniser vos dialogues
- Vous avez des retours utilisateurs quant à vos dialogues
Et si vous avez suivi les étapes des articles précédents, vous avez la personnalité de votre assistant ainsi que sa voix…. Je crois qu’on peut dire que vous êtes prêts !
Bon ce n’est pas encore terminé, il y a effectivement la partie sonore dont je vous parlais plus haut, ou même tout ce qui est du développement… Mais vous avez tous les éléments et l’expérience que vous proposerez n’en sera que plus agréable, fluide et pertinente ! BRAVO
Retrouvez l’article Comment créer un assistant vocal ? 1/3 – Définir sa personnalité
Retrouver l’article Comment créer un assistant vocal ? 2/3 – Choisir une voix qui plait à mes futurs utilisateurs