On compte aujourd'hui des dizaines de milliers de skills, fonctionnalités conçues et développées sur Alexa. Elles vont des flash actu de France Info à la commande d’un Uber en passant par les simulations de bruit pour faire peur aux voleurs (et oui, c’est bien vrai !).
Ayant participé à la création de la skill SNCF, voici mon retour d’expérience et mes conseils sur les 7 étapes pour apprivoiser Alexa.
Ce REX a été présenté par moi-même etCamille LEBLOND, UX Designer d’Axance lors du meetup LPCx. Nous organisons un meet up produit par mois, rejoignez-nous!😁
1. Définir les bons use cases : partir des principaux usages existants🚄
Côté SNCF, nous ne partions pas de rien, puisque plus de 3 millions d’utilisateurs utilisent l’application SNCF chaque mois. L’ambition était de transformer cette application en véritable assistant du quotidien, capable d’intégrer des solutions alternatives de transports (covoiturage, vélos, etc.) et d’accompagner les utilisateurs dans tous leurs déplacement en cas de problème.
De votre côté, si vous avez déjà une app, il est pertinent de partir des usages principaux de vos utilisateurs sur cette app. Dans notre cas :
- Définir un itinéraire porte à porte partout en France.
- Obtenir les horaires d’une ligne.
- Connaître la circulation des trains et être au courant des perturbations en temps réel.
Si vous n’avez pas d’app, réfléchissez aux 2 ou 3 questions principales que se pose votre utilisateur. Ne partez pas dans une liste exhaustive, vous enrichirez votre skill peu à peu.
2. Penser au contexte d’utilisation👂
Alexa est un assistant vocal. L’environnement sonore dans lequel il va être utilisé est donc crucial. Or, en tant que Product Managers, nous pensons naturellement à l’UI graphique : beaucoup de visuel, un peu de tactile mais moins au son.
Dans le cas d’Alexa, posez-vous les questions suivantes : quel est le niveau sonore dans lequel va être utilisée la skill ? Dans une maison au calme ? Dans une voiture avec le bruit du moteur ? A l’extérieur avec le bruit de la ville ?
Notre recherche utilisateur a montré que le principal contexte d’utilisation pour la skill SNCF était chez soi, juste avant de partir. Un environnement calme donc mais un utilisateur pressé ou stressé par son départ imminent.
3. Réfléchir en amont à vos contraintes fonctionnelles et techniques🛠️
Il faut en amont “penser voix”. Or, l’information est rarement adaptée à de la synthèse vocale, sauf si vous travaillez pour la radio ou avez déjà un assistant vocal in-app.
2 contraintes majeures dans notre cas :
- la complexité des itinéraires, qui est plus facile à représenter de façon graphique
- le fait que l’information sur les perturbations en temps réel soit livrée par des sources externes, avec des textes qui ne sont pas adaptés à de la synthèse vocale.
Enfin, il faut prendre en compte les contraintes imposées par Amazon. Vous pouvez choisir le tone of voice du script mais vous vous intégrez dans un écosystème existant car Amazon souhaite qu’Alexa ait une personnalité propre. Ainsi, Alexa vouvoie, et vous ne pouvez pas déroger à cette règle. Il y a donc une réflexion à mener en termes d’identité de marque.
Vous pouvez récupérer certaines informations que l’utilisateur a partagées dans son compte Amazon, l’adresse de son domicile notamment. Mais au final, peu de données vous seront accessibles grâce à Alexa.
4. Décrire des users flows très simples, puis les enrichir 🔀
Il est indispensable de cartographier toutes les interactions qu’Alexa aura avec les utilisateurs. Grâce à cette visualisation, vous définissez ce que l'utilisateur peut faire ou ne pas faire avec la skill et la manière dont il va naviguer avec. Cela permet de partager et collaborer facilement, à la manière d’un wireframe pour une interface graphique.
L’idéal est de commencer par décrire le parcours initial...
Voyageur : Alexa, quels sont les prochains départs de train dans ma gare ?
Alexa : Quelle est votre gare de départ ?
Voyageur : La défense
Alexa : Et votre gare d’arrivée ?
Voyageur : Marne-La-Vallée
Alexa : Le prochain RER A au départ de La Défense et à destination de Marne-La-Vallée est prévu dans 5 minutes. Le suivant est dans 12 minutes.
… puis d’enrichir le flow avec tous les cas à la marge, notamment
- les requêtes partielles. Si on reprend l’exemple, si l’utilisateur dit “Alexa, comment aller à Marne-la-Vallée ?”, il manque le début de l’itinéraire. Alexa doit donc demander la gare de départ, sans la gare d’arrivée.
- des cas d’erreurs de l’outil : Alexa ne reconnaît pas le nom de la gare
- des cas aux limites de votre application : si l’utilisateur demande un train pour la Belgique, Alexa doit pouvoir lui répondre que les trains à l’international ne sont pas inclus.
Les cas d’erreur sont une occasion de guider l’utilisateur dans l’utilisation de l’interface. Vous pouvez notamment lui donner des modèles de phrases avec lesquelles la skill fonctionnera correctement : “Pour demander le trajet entre deux gares, dites simplement …”
Nous avons aussi distingué les flows pour les nouveaux et les anciens utilisateurs.
- pour les nouveaux utilisateurs, un message de bienvenue présente des exemples de requêtes possibles avec les phrases utilisées
- à partir de plusieurs utilisations, nous considérons que l’utilisateur devient à l’aise avec la skill et nous supprimons le message de bienvenue.
5. Ecrire les scripts : les quatre bonnes pratiques ✍️
Avec Camille, j’ai lu beaucoup de bonnes pratiques pour écrire les scripts pour un assistant vocal. En voici 4 qui m’ont beaucoup aidé :
- Utiliser des marqueurs pour structurer et ordonner vos réponses. Naturellement, nous utilisons des mots de liaisons pour structurer nos réponses : “tout d’abord”, “puis” etc. Mettez-les à propos dans vos scripts, le texte n’en sera que plus fluide et naturel, et guidera naturellement l’utilisateur tel un fil d’Ariane sur un site web
- Trouver un juste milieu entre une information complète et une réponse concise. Le choix du niveau d’information est essentiel. Ex : faut-il donner le prochain train et sa voie puis le train suivant et sa voie ? Finalement, nous avons tranché en considérant que l’information principale qui intéressait le voyageur sur le point de partir de chez lui était les horaires de train, et nous n’avons pas ajouté les voies.
- Favoriser la découverte progressive des fonctionnalités. L’utilisateur apprend à se servir de l’assistant vocal, ce n’est pas inné. Il faut donc lui proposer de nouvelles fonctionnalités au fur et à mesure de ses utilisations de la skill. Ainsi, enregistrer un trajet favori n’est pas pertinent au départ. Si une même requête revient 3 ou 4 fois, alors Alexa peut suggérer d’enregistrer un itinéraire.
- Installer une routine tout en variant les réponses. À nouveau, il y a un équilibre à trouver entre le fait d’habituer l’utilisateur à un certain mode de fonctionnement et la volonté d’éviter un comportement trop machinal donc ennuyeux. Il faut que les réponses semblent naturelles. Pour cela, il faut varier les scripts : on dira “le trafic est fluide sur le RER B” comme “tout va bien ce matin sur le RER B”.
Pour ce qui est de la voix, deux options sont possibles : soit vous envoyez le script et Alexa synthétise la voix, soit vous enregistrez toutes les réponses audio. Vous pourrez alors avoir une voix personnalisée, mais la constitution de la base de réponses sera beaucoup plus lourde.
6. Anticiper la formulation des requêtes🗣️
Après avoir fait tout ce travail sur ce que répondait Alexa, vient l’autre pan : comment l’utilisateur va interagir avec la skill ?
La première question à vous poser est celle de l’accès à votre skill. 2 cas :
- vous faites partie des top tiers, les heureux élus qui sont totalement intégrés dans Alexa comme Deezer
- soit il faut demander à Alexa de lancer le skill SNCF. “Alexa, demande à la SNCF de me donner le prochain train de La Défense vers Marne-la-Vallée”
Puis, le Product Manager doit réfléchir aux mille façons de poser une même question.
Pour qu’un intent (intention) soit bien compris, vous devez constituer plusieurs centaines d’exemples de requêtes. Et là, magie 🧞, vous découvrez Amazon Echo Utterance Expander.
Il vous permet de créer des variantes à partir des différentes formulations possibles d’une même intention : impératif / interrogatif / 1ère personne / conditionnel.
Voici par exemple les différentes façons de demander l’itinéraire d’une gare A à une gare B:
1.2.3.4.5.6. Et à toutes les étapes, tester ⚗️
Le test n’est pas UNE étape, il doit être présent partout. Il n’est pas nécessaire d’attendre qu’un prototype soit créé pour débuter vos tests. Au contraire, vous gagnerez du temps en validant vos hypothèses et en testant la pertinence de vos différents use cases au fur et à mesure.
Ainsi, il est possible d’entraîner la skill aux différentes requêtes qui vont lui être posées et donc de rendre l’échange le plus naturel possible.
Quelques tips :
- Testez les uses cases en utilisant la technique du magicien d’Oz. Une personne joue le rôle d’Alexa et répond à l’utilisateur.
- Créez un prototype avec des réponses écrites en dur et n’allez pas chercher de vraies données, donc pas de développement nécessaire ! Vous vous concentrez sur les différentes questions utilisées et sur la reconnaissance vocale.
- Allez rencontrer vos utilisateurs… mais pas dans un café ! Nous sommes allés dans un Starbucks pour observer comment les utilisateurs s’adressaient à Alexa. Or le bruit était tel que cela rendait les tests difficiles. Avec la musique et le bruit de fond, Alexa entendait mal !
- Quand vous testez, vérifiez quelques minutes plus tard que vos utilisateurs se souviennent de la réponse. Vous saurez ainsi si vous avez été clairs.
Nos premiers tests ont montré que la phrase d’accueil était bien trop longue : les gens posaient la question tout de suite, en coupant le script. A l’inverse, les informations concernant le trafic étaient trop limitées.
Voici un article très concret sur lapièce idéale pour faire vos tests, écrit par Dave Berol.
Comme pour chacun de nos tests utilisateur, les résultats sont ensuite partagés avec l’ensemble de l’équipe via un document qui synthétise le profil des personnes interrogées, les enjeux et condition du test ainsi que les principaux insights
Après le prototype, vous devez tester la bêta. Le but est d’entraîner la skill et de trouver toutes les requêtes auxquelles on n’a pas pensées pour enrichir les flows et les scripts.
Nous avons impliqué l’équipe de développeurs très tôt dans les tests. Un lead developer backend a participé aux ateliers de création des parcours, afin de valider la faisabilité des scénarios et générer de nouvelles idées comme l'exploitation de certaines données présentes dans les API pour enrichir les réponses.
Nous avons ensuite sollicité les développeurs, la relation client, les testeurs et d’autres Product Owners de l’équipe pour enrichir nos "utterances", les phrases d'exemple qui permettent de solliciter Alexa. Enfin, nous les avons également intégré lors de la recette afin qu'ils posent toute sorte de questions relatives aux scénarios que nous avions développés.
7. Analyser les données📊
Amazon vous fournit quelques données sur l’usage de votre skill :
- nombre d’utilisateurs uniques qui utilisent la skill
- nombre de sesssions et de sessions par utilisateur, avec le nombre de session en échec
- nombre d’utterances ainsi que leur intent associé, avec le nombre de phrase en échec
- volumétrie d’appel sur les différents intents de votre skill, avec les succès et les échecs
- rétention
- principaux parcours utilisateurs
Mais vous ne saurez pas les phrases vraiment prononcées. Question de confidentialité. Si vous souhaitez pousser plus loin l’analyse des comportements de vos utilisateurs, vous pouvez vous appuyer sur des outils dédiés tel que Botanalytics.
In a nutshell🌰
Vous vous lancez ? Alors ne partez pas sans retenir ces 4 points :
- Commencer simple et itérer
- Pensez à l’environnement de votre utilisateur quand il parlera avec Alexa pour déterminer les bons cas d’usage
- Permettez une découverte progressive de l’assistant dans le temps en introduisant de nouvelles fonctionnalités au fur et à mesure que l’utilisateur se familiarise avec votre skill
- Adaptez-vous au vocabulaire de vos utilisateurs, ce n’est pas eux qui le feront.