Les tests d’utilisabilité en interface vocale nécessitent souvent des outils assez complexes (cf. Nexus[1], Database Systems Corp.[2]). Pour l’un de nos projets qui impliquait un système téléphonique de renseignements automatisés à touches, nous avons cherché une solution de test qui soit flexible, rapide à monter, qui offre une simulation assez naturelle d’un appel téléphonique tout en permettant la capture de l’appel et d’un certain nombre d’événements durant cet appel, facile à modifier et surtout, peu coûteuse.

Nous avons donc conçu une application Flash facile et adaptée pour simuler l’appel d’un utilisateur à une interface vocale et qui présentait les caractéristiques suivantes:

1.    Interface simple à utiliser ;
2.    Peu exigeante : l’exécution d’une telle application nécessite seulement un navigateur internet et l’installation du FLASH player;
3.    Simple à modifier : les tests étant itératifs, des changements ont été apportés à la structure de l’application après chaque test (trois au total);
4.     Permet de gérer la vidéo et l’audio en streaming et peut fonctionner avec un logiciel de capture de son et de vidéo;
5.    Facilite le recueil et l’analyse de données : l’outil nous permettait de capturer, pour chaque appel, le type de touche appuyée, le chemin parcouru dans la RVI, le temps passé à l’écoute des messages etc. Toutes ces données sont essentielles pour une bonne analyse de l’utilisabilité d’une application RVI.
6.    Facilement transférable à d’autres applications de type RVI.
7.    Peu coûteuse : un développeur FLASH a développé cet outil pour nous en 2 semaines.

Description de l’outil (Front End)

Il s’agit d’un simple écran qui reproduit un téléphone virtuel piloté et vu seulement du  modérateur. Au fur et à mesure que le participant entend les instructions, il appuie sur les touches du clavier numérique externe et entend les instructions subséquentes. Les messages vocaux sont joués sur la sortie audio de l’ordinateur.
Le modérateur peut également inscrire le nom et le prénom du participant, le type de scénario testé et le persona. Il démarre l’application, l’arrête lorsque le participant a fini sa tâche et peut interrompre à tout moment l’écoute du système ou la rejouer.

Durant l’appel, les touches appuyées s’affichent à l’écran les unes à la suite des autres ce qui permet de voir le chemin parcouru en temps réel, d’éviter les erreurs lors de la prise de notes et de pouvoir compiler les points critiques de l’interface rapidement après chaque participant.
Des logs sont par ailleurs disponibles pour retracer toutes les interactions avec le clavier durant la session : le nombre de fois où le zéro est appuyé, le temps de non-action, etc.

Le système de contrôle (Back End)

L’application qui gère la structure de l’interface permet d’attribuer à chaque option du menu, une touche du clavier téléphonique et de créer ainsi les parcours de l’application vocale entre les menus, les options, les messages, d’y attribuer les fichiers audio codés en mp3, de prendre en compte la gestion des erreurs, des non-actions, les redirections, et l’interruption d’un message.

Exemple :
La création d’un menu se fait de gauche à droite (cf. schéma).
1. En cliquant sur ¨+¨on crée un nouveau nœud, en cliquant sur ¨-¨ on en supprime un. Ce que l’on entend par ¨nœud¨ est un menu ou un message ou un choix de la langue, etc.

2. On le nomme, on lui attribue un type (menu, message, etc.) selon une nomenclature que l’on a défini à l’interne. Le fichier audio en mp3 (enregistré en français ou en anglais) devra avoir le même nom puis on lui assigne un temps pendant lequel l’utilisateur doit faire une action (ici par exemple 3secondes). Dans la zone de droite, on lui assigne chaque touche du clavier téléphonique et on définit le comportement en cas de non-action ou d’erreur. Exemple : quel message à faire jouer si aucune touche du clavier n’a été pressée pendant les 3 secondes. La modification de la structure est donc très rapide.

Conclusion

Les résultats ont montré que le FLASH, utilisé principalement pour les interfaces graphiques, est aussi très intéressant pour le prototypage d’interface vocale.
Il permet de développer rapidement une application flexible qui reproduit un appel téléphonique et rend ainsi compte efficacement de l’expérience utilisateur.

Le système a l’avantage d’être transposable à d’autres applications vocales et permet d’envisager des utilisations futures pour des tests d’utilisabilité à distance puisque le FLASH rend possible le développement à la fois des outils multimédia interactifs en local et en ligne.

Néanmoins, l’outil est à améliorer afin de coupler l’application à un véritable téléphone et ainsi ressembler le plus possible à un appel fait de chez soi.

Références webographiques
[1] Franz Neeser. Testing IVR Systems, White paper. Nexus Telecom AG, Switzerland. May 2005.
http://www.nexus- ag.com/fileadmin/documents/Whitepaper/White_Paper_IVR_Testing_
Nexus8610_Ed_2.2.pdf

[2] Database Systems Corp.

Source image:
Image ordinateur portable: openclipart.org/media/files/aurium/4163

Yu Centrik a travaillé sur plusieurs projets d’évaluation d’Interface à Réponse Vocale Interactive (RVI). Nous avons ainsi procédé à l’évaluation de quatre systèmes téléphoniques automatisés pour différents organismes gouvernementaux (fonctionnant à touches et non par reconnaissance vocale). En tout, 74 participants issus du grand public ont évalué ces systèmes sur des périodes différentes.

Parmi les freins ergonomiques que nous avons identifiés, l’un des plus fréquents est lié à la terminologie utilisée. Ce que nous entendons par terminologie, c’est à la fois ¨l’ensemble des termes propres à un domaine¨[1] , soit le lexique (le vocabulaire, le jargon, les libellés d’options utilisés, etc.) mais aussi la syntaxe avec la formulation d’une option ou d’un message.

Les points problématiques les plus courants sont dûs d’une part à une terminologie qui n’est pas adaptée au contexte de vie des appelants ni au style auditif de l’interface, mais aussi à un manque de précision et de constance dans les termes ainsi qu’à des options de menus ou des messages complexes qui comportent souvent du jargon.

Ainsi, d’après nos observations, 43% des problèmes sont liés uniquement à la terminologie utilisée.

Quels problèmes ? Quelles pistes de solutions ?

Voici cinq points que nous jugeons incontournables afin de minimiser les problèmes terminologiques.

1. Choix des mots
Pour connaître le niveau à donner à la terminologie, une écoute massive des appels et une transcription mot pour mot des raisons d’appels telles qu’énoncées par les appelants sont nécessaires comme approche. Tel que l’évoquent Garden-Bonneau & Blanchard (2008), il faut structurer le dialogue de la façon dont pensent les appelants et suivant les situations de vie qu’ils rencontrent. Personnaliser une option facilite aussi son identification.

Exemple : l’option ¨Pour un accident de la route, faites le 1¨ sera mieux accueillie et identifiée par ¨Vous avez subi un accident de la route ?, faites le 1¨.

2. Simplicité
La complexité des termes ou des informations est synonyme de perte de temps, de frustration et peut donner l’impression aux appelants d’être ¨incapables¨ de comprendre alors que le système n’est pas adapté. Les RVI étant séquentielles et peu interactives, le mot d’ordre est la simplicité.
Très souvent, l’appelant a un mot-clé en tête. ¨Parce qu’il oublie vite ce qu’il entend¨[2], il est important de privilégier une option pour un mot-clé en faisant attention à l’ordre des mots, d’utiliser des phrases courtes et d’éviter à la fois les confusions auditives et les termes superflus.

Exemple : ¨Pour prendre un rendez-vous avec un réparateur, pour modifier ou annuler un rendez-vous déjà pris ou pour connaître les coûts et les services de réparation, faites le 2¨.

Ici l’option est longue, parle de deux cas de situation différents (le rendez-vous et le coût de réparation), et la similarité auditive des termes ¨prendre – pris¨ et ¨réparateur-réparation¨ embrouillent la compréhension.

On choisirait davantage:
Pour prendre, modifier ou annuler un rendez-vous, faites le 1;
Pour connaître nos services et nos prix, faites le 2;

3. Précision, clarté
Un seul terme dans une option pourra faire que l’option ne sera pas choisie.  Il est donc essentiel d’être très explicite et d’éviter toute ambiguïté.

Exemple 1 : l’option ¨Si vous quittez le Québec, faites le 4¨
Quitter le Québec veut-il dire de façon permanente, temporaire ? L’appelant qui part en vacances se reconnaît-il dans cette option ? En notant que les hésitations entraînent des erreurs dans le système et qu’au bout de deux ou trois erreurs, l’utilisateur est transféré à un préposé, l’option ne répond ni aux besoins de l’appelant ni aux objectifs du client de l’aiguiller au bon préposé.

Exemple 2 : ¨Si vous recevez <telle prestation>, faites le 1 ; Sinon, faites le 2 ;¨

Les participants hésitaient entre les deux options. Si l’on précise le ¨sinon¨ par exemple en disant ¨Si vous ne la recevez pas encore, faites le 2¨, l’appelant identifie l’option plus facilement, fera sa sélection auditive en fonction de sa situation, ce qui évitera de faire des erreurs.

4. Constance
Un vocabulaire homogène permet de minimiser la confusion et d’assurer une cohérence à travers toute l’application, ce qui renforce l’image mentale que l’appelant peut se forger du système[3]. Le Centre d’Expertise des Grands Organismes recommande par ailleurs que la terminologie soit homogène à tous les canaux de communication.

Exemple: ¨Pour des questions relatives à votre versement, faites le 2¨ ;
¨Vous n’avez pas reçu votre paiement, faites le 3 ;

Parler de ¨versement¨ puis de ¨paiement¨ peut sembler identique mais pour un appelant, la question vient rapidement : mais qui paye ? Qui verse ? Est-ce la même chose ?
Sachant que la prise de décision dans le système doit être rapide, il est essentiel d’éviter de créer le doute pour l’appelant.

5.  Vulgarisation
Le jargon est une grande source de confusion pour un appelant puisque contrairement au web où l’explication peut être affichée par un lien ¨plus d’infos¨ par exemple,  dans un système téléphonique automatisé, il est extrêmement contraignant pour l’appelant d’aller chercher de l’information complémentaire. Une solution est d’associer le jargon de l’organisation à une ¨courte¨ explication.

Exemple :
Au lieu de ¨Pour des informations sur le formulaire E10411, faites le 1 ;¨ on pourrait par exemple choisir : ¨Pour obtenir le formulaire E10411 qui couvre vos dépenses de santé dans l’Espace Européen, faites le 1;¨.

Les appelants peuvent identifier le formulaire par son numéro ou sa fonction. L’option s’adapte à l’expérience de l’appelant.

Conclusion

La terminologie est le critère le plus difficile à mettre en pratique puisque le langage invite à de multiples interprétations. C’est pourquoi il est important de mener une analyse approfondie du vocabulaire utilisé par les appelants au travers d’écoutes mais aussi de procéder à des tests d’utilisabilité rigoureux.
Yu Centrik travaille actuellement sur la préparation d’un cours sur la conception en interface vocale. Ce cours sera présenté à Québec à l’automne prochain. Pour en savoir plus, contactez-nous !

Références
Centre d’Expertise des Grands Organismes; (2008); Système de réponse vocale interactive : les meilleures pratiques pour les interfaces vocales. http://www.grandsorganismes.gouv.qc.ca/pages/index_f.aspx?DetailID=92

D. Gardner-Bonneau & H.E. Blanchard, (2008); Human Factors and Voice interactive Systems, Second Edition; Springer, New York, USA.

Sources images
Image Téléphone : http://www.cabinvacationgetaway.com/Contact.php
Image user emoticon : http://www.brothersoft.com/fast-icon-users-for-linux-168235.html

[1] Selon l’Office Québécois de la Langue Française

[2] Gardner-Bonneau, H.E. Blanchard, (2008).

[3] Conseil de l’experte : ce critère devrait d’ailleurs être appliqué à travers toute l’organisation pour améliorer l’expérience client: site Web, service clientèle, dépliants, points de services.

Lors de l’évaluation d’interfaces graphiques, de type site web, j’applique entre autre, les heuristiques de Bastien/Scapin et Nielsen et j’analyse la structure du système au travers d’une architecture de l’information. Une page du site visualisée à l’écran a donc son équivalent schématique dans l’architecture.

Il y a une correspondance entre le produit et sa modélisation. Tous deux sont bidimensionnels et la navigation est similaire entre l’application et sa représentation ; les actions de l’utilisateur peuvent ne pas être successives les unes aux autres ni liées entre elles.

Récemment, nous avons été amenés à poser un diagnostic sur une interface vocale. Il s’agissait d’un service téléphonique de renseignements automatisés.

Par opposition au support visuel persistant des applications graphiques, l’information recueillie lors de l’écoute des segments vocaux d’un système téléphonique ne permet pas d’être retenue en totalité. Le recours à la représentation graphique devient donc indispensable. Une schématisation de la structure, de la navigation et du contenu des messages a ainsi permis de comprendre l’expérience utilisateur au sein du processus.

Cela dit, il peut se créer, à ce moment de l’évaluation, un conflit.
Il n’y a, en effet, plus de correspondance entre le produit et sa modélisation puisque l’étude de l’application vocale se fait principalement au travers du support de travail visuel.

Or, ce que l’on voit schématiquement est entendu par l’utilisateur et ce, de façon séquentielle ; chaque instruction en suit une autre et l’appelant ne peut naviguer dans l’application comme il le fait sur un site web.

La schématisation a alors, en quelque sorte, tendance à minimiser l’ampleur de l’effort auditif, mnésique et attentionnel fourni par l’usager et la contrainte pas-à-pas de l’application.

C’est pourquoi, j’ai toujours dû garder à l’esprit qu’étant donné la seule exploitation du mode auditif, chaque message ou option proposé demanderait un traitement cognitif plus important à l’utilisateur pour être entendu, écouté, assimilé et compris.

Il en est de même à l’étape du design ; chaque modification au sein de l’application devrait être testée auprès d’utilisateurs pour juger de sa pertinence « auditive ».

Ainsi, nous devons toujours faire attention au support utilisé pour nos évaluations et adapter notre analyse en fonction du type d’interface étudiée et des exigences cognitives qu’elle demande à l’utilisateur.