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

La gestion de centre d’appels est une discipline en soi (call center management).
Une partie de cette discipline consiste à assurer la conception des systèmes qui permettent aux représentants au service à la clientèle de procéder à l’ensemble des transactions qui peuvent être apportées au compte d’un client. Une des problématiques souvent rencontrées en centres d’appels est la productivité des ressources (les représentants) et lors d’analyses, on se rend notamment à l’évidence que les systèmes informatisés qui sont mis à leur disposition pour exécuter leurs tâches sont sous-optimaux; d’où les nombreux projets de refonte de ces systèmes.
Notre firme a été mandatée à quelques reprises déjà pour travailler à la refonte de systèmes de centre d’appels et je dois dire que j’aime toujours travailler sur de tels projets.

J’apprécie le fait que les processus soient complexes, les impératifs de qualité et de productivité élevés et les caractéristiques des utilisateurs très variées. De beaux défis pour des designers !

J’apprécie aussi que, sur de tels systèmes, le design ait un double impact : à la fois du côté de la productivité du représentant au service à la clientèle (et sur la satisfaction qu’il a dans son travail) mais aussi, du côté de l’expérience du consommateur à l’autre bout du fil et donc, sur la satisfaction globale envers la marque.
Pour une seule intervention de design, l’impact est donc double, à la différence de ce qu’il peut être lorsque l’on conçoit une application ou un site du strict côté du consommateur.
Cependant, si les impacts sont amplifiés, les risques ne le sont pas nécessairement en proportion; ce qui importe c’est de bien connaître les règles et principes qui dirigent la conception de systèmes en centres d’appels et les appliquer rigoureusement.

Voici quelques-uns des principes que nous veillons à appliquer lors de la conception de systèmes en centre d’appel :

1 - Connaissez votre centre d’appel

Vous devez connaître comme si vous y étiez né le business auquel vous vous attaquez (service public ou privé, ventes de biens ou de services ou les deux, centre de dépannage, support technique, etc.).
De même, les règles d’affaires, les politiques et procédures, la formation des gens (durée, coûts, formation initiale versus continue), les indicateurs de performance (nombre d’appels traités, temps d’attente) et l’organisation des équipes (niveaux d’expertise, taux de roulement, quarts de travail, aiguillage par compétence…), plus rien ne doit vous être inconnu.

2 - Observez sur le terrain

On ne le dira jamais assez : OBSERVEZ les représentants, SUR LEUR TERRAIN. Assoyez-vous à côté d’eux et écoutez les questions qu’ils posent au client, les formulations qu’ils emploient, leur jargon, les informations qu’ils cherchent, les aide-mémoires qu’ils se mettent partout sur leur bureau. Émerveillez-vous de tous les trucs qu’ils trouvent pour faire patienter le client lorsque le système tombe en panne ou qu’ils ne trouvent tout simplement pas l’information demandée…
Ouvrez vos oreilles et vos yeux d’analystes! Dans ce domaine, ce qui est lu reste abstrait alors que ce qui est vu est compris instantanément et ouvre sur des perspectives créatives.
Sachez la différence entre la tâche prescrite et la tâche réelle (ce qui est montré en formation versus ce qui est fait sur le terrain).
Modélisez la tâche réelle et identifiez les opportunités d’automatisation et d’amélioration des interfaces pour mieux soutenir la tâche.
N’oubliez pas que ce qu’on veut dans la plupart des cas, c’est diminuer l’astreinte cognitive sur les gens, pour augmenter leur disponibilité d’écoute. Cette disponibilité cognitive est d’autant plus importante si l’on exige des représentants qu’ils vendent des produits dérivés dans le court laps de temps que dure la conversation téléphonique. Ils doivent être “tout” là…

3 - Concevez par prototypage

Avant toute chose: les superviseurs, les formateurs et les représentants ne SONT PAS des concepteurs de systèmes !
Bien qu’ils possèdent sur le bout de leurs doigts les règles d’affaires et les politiques du centre d’appel, bien qu’ils connaissent à fond leur clientèle, ils ne sont pas qualifiés pour concevoir et tester les interfaces qui leur permettront de faire efficacement leur travail.
Le corollaire à ça: les programmeurs ne devraient pas non plus avoir une trop grande latitude à la créativité. Même s’ils veulent bien faire en apportant des améliorations, il faut savoir que les designs ont été rigoureusement testés et validés et que le moindre changement peut avoir un impact sur la performance.

Bien avant les méthodes Agile, je concevais par prototypage rapide et le plus interactif qui soit possible, et je pense que je ne me suis jamais gourée en appliquant cette méthode: plusieurs petits prototypes partiels testés et améliorés valent mieux qu’un exhaustif, long à faire, et sur lequel il est trop compliqué de revenir en arrière…

Basez votre design sur des cas typiques et des scénarios catastrophes, qui feront en sorte que l’interface supporte les cas problèmes tout en étant optimisée pour les cas ” typiques “.
Je recommande aussi la mise sur pied d’un groupe pilote, composé autant de représentants novices que d’experts, qui suivra le projet dans son ensemble et participera à des séances de brainstorming (rigoureusement animées par vous - rappelez-vous que les utilisateurs ne sont pas des concepteurs) mais qui vous en apprendra beaucoup sur les cas typiques et moins typiques et sur les besoins de soutien des novices et les tactiques des experts.

4 - Testez, testez, testez encore!

Plusieurs tests successifs sur les prototypes précédemment identifiés vous permettront de trouver plus de 80% des irritants du système et de les régler dans les prototypes ultérieurs.
Combien de tests ? Allez, puisque vous voulez un chiffre, disons que quatre tests successifs devraient permettre d’amener le design à une bonne maturité.
Identifiez un échantillon représentatif de participants aux tests. Le groupe pilote sera votre première référence pour l’évaluation des prototypes: il pourra noter les améliorations ainsi que les régressions du système (cela peut très bien arriver).
Cependant, ce groupe ne devrait pas être l’unique référence pour l’évaluation de prototypes : il est bon aussi d’intégrer des gens qui n’ont pas participé au groupe pilote pour avoir des commentaires issus de ceux qui n’ont encore rien vu.

5 - Gérez le changement

Un nouveau système amène inévitablement son lot de changements dans la culture et les pratiques d’entreprise.
Un système de parrainage ou de mentorat où les gens du groupe pilote sont jumelés à d’autres pour un transfert d’expertise peut aider à réduire le potentiel de résistance au changement: vu qu’ils ont aidé à mettre le système sur pieds, ils sont plus motivés à faire en sorte que leurs pairs l’apprécient.
Mais le changement d’outil de travail doit se faire avec le plus grand souci du respect des gens possible. Les gens ne sont pas réfractaires au changement, mais ils veulent comprendre pourquoi on change leurs habitudes et qu’est-ce que cela va leur apporter de mieux dans leur travail.
Un bon design fera en sorte que cela soit évident à leurs yeux.

Notre laboratoire de test d’utilisabilité dispose d’un environnement logiciel pour la capture, l’enregistrement, l’analyse et l’interprétation complète de tout événement observable lors de tests avec des utilisateurs. Comme nous nous intéressons aux comportements des utilisateurs, les verbalisations, les expressions faciales et les mouvements du regard ainsi que les saisies au clavier et les mouvements de la souris, nous utilisons aussi d’autres logiciels.

Depuis six mois nous cherchons à perfectionner les pratiques et les résultats des évaluations heuristiques effectuées par l’équipe de Yu Centrik. Dans ce type d’activité, nous nous intéressons à évaluer la qualité de « l’expérience de l’utilisateur » au delà de l’utilité ou de l’utilisabilité qu’un dispositif ou qu’un système interactif puisse offrir.

Le protocole de test est un document qui décrit la méthode à suivre pour effectuer des tests d’utilisabilité et qui sert de base de discussion entre les équipes du produit testé et Yu Centrik.

Le but général des tests avec des utilisateurs est d’identifier les principaux problèmes d’utilisabilité du produit.

Les tests d’utilisabilité permettent d’observer le comportement des utilisateurs lorsqu’ils effectuent des tâches supportées par le produit/site afin d’évaluer la facilité d’utilisation de celui-ci et de déterminer les facilités et les difficultés rencontrées lors de son utilisation.

Des objectifs de tests sont établis dès le début du projet et seront mesurés à l’aide de scénarios élaborés avec le Client.

Lors des tests d’utilisabilité on demande aux participants d’effectuer des tâches précises et de verbaliser au fur et à mesure de l’accomplissement des différents scénarios. Si les tests portent sur la performance du système, alors la verbalisation sera effectué après l’accomplissement de la tâche.

Un profil du participant type à recruter a été créé de concert avec le Client. L’échantillon choisi est constitué d’un nombre suffisant de participants représentatifs de la clientèle du produit.
Les caractéristiques du profil des participants ou Personas servent à appuyer le recrutement.

Le jour du test, le participant est accueilli dans les locaux de Yu Centrik. Il rencontre la modératrice ou le modérateur et reçoit des indications sur le déroulement du test. Chaque session de test dure 60 minutes sauf pour les tests d’oculométrie qui peuvent durer 90 minutes.

Le participant accomplit les scénarios de tâches de façon individuelle. Il est encouragé à verbaliser après qu’il ait accompli les différents scénarios prévus pour son profil. Le modérateur l’écoute et pose des questions. Un observateur prend des notes. Chaque session de test est filmée et observée en temps réel par les représentants du Client.

Une appréciation qualitative est aussi recueillie après chaque tâche afin de comprendre les motivations, les perceptions et l’expérience vécue. Les données sont ensuite colligées, compilées et analysées.

Un rapport de tests comprenant une analyse des résultats ainsi que des recommandations est ensuite remis et présenté au client.

Un suivi des corrections est toujours apprécié par les ergonomes des interfaces car cela leur permet de bien s’assurer que les recommandations ont bien été comprises.

En quoi les tests d’utilisabilité sont-ils différents lorsque effectués en présentiel ou à distance ? Voici une liste comparative d’arguments qui pourrait vous être utile à mieux comprendre les avantages et les inconvénients de chaque méthode.

Tests d’utilisabilité en présentiel
Points forts

• L’environnement technologique est stable et contrôlé
• La technologie est plus performante pour les tests de différents systèmes interactifs (Web, logiciels, mobilité, télé interactive, interfaces vocales, etc.) et aussi avec technique d’oculométrie
• Tous les participants exécutent les tâches dans un environnement identique ce qui rend les données de performance plus stables
• Les tests sont plus faciles à mettre en place du point de vue technique
• Le modérateur est près du participant et peut observer le non-verbal, les hésitations et réagir vite
• Les captations audio, vidéo et expressions faciales sont enregistrées
• Les clients observent en temps réel et prennent un temps de pause dans leurs agendas bien remplis pour se ressourcer et en apprendre sur leurs utilisateurs

Points faibles

• Le comportement du participant peut être biaisé par un souci de bien performer même si on le rassure que “c’est le système qui est testé et pas lui”
• Le recrutement est plus difficile car les gens sont très sollicités à participer à des groupes de discussion
• Les tests sont limités aux participants locaux sinon un déplacement des équipes est requis
• Le taux d’absentéisme est plus grand à cause du déplacement, du climat, de surcharge de travail, d’abandon spontané à la sortie du travail, etc.)

Tests d’utilisabilité à distance
Points forts

• Le participant est dans son environnement naturel à la maison ou au bureau et dans sa réalité vécue
• La technologie offre la possibilité d’effectuer des tests partout sur la planète et dans la langue maternelle des participants
• Le participant est plus à l’aise car il utilise un équipement qu’il connaît bien
• Le participant semble moins stressé, plus près de son comportement habituel et peut-être aussi moins tolérant
• Le modérateur voir tout ce que le participant fait à l’écran et entend ses propos
• Le modérateur entre un peu dans la vie privée du participant par le biais du principe d’écran partagé
• Le client peut assister aux tests d’un lieu distant
• Le système permet une captation des interactions et audio de toute la session
• Le recrutement est plus facile car la contrainte du déplacement pour le participant est éliminée

Points faibles

• La logistique à mettre en place est plus importante du point de vue technique, plusieurs pré-tests et plus de ressources internes sont nécessaires
• Des problèmes techniques de dernières minutes et incontrôlables peuvent apparaître
• Une bande passante haute vitesse est quasi indispensable si on veut éviter les délais trop importants
• L’utilisation du cellulaire pour les conversations audio est contraignante et un téléphone fixe main-libre est recommandé
• La planification des tests est plus compliquée à cause du décalage horaire
• On remarque une difficulté d’expression des idées lorsque la langue de communication lors des tests est la 2ème ou 3ème langue parlée du participant
• Sans captation vidéo le non-verbal s’avère impossible

Dans tous les cas, n’arrêtez pas de tester avec de vrais utilisateurs votre produit, leurs commentaires sont tellement inspirants qu’il serait fou de s’en passer !

Plusieurs entreprises désireuses de concevoir ou de faire évoluer leur site Web négligent d’inclure dans leur processus de développement l’activité de modélisation de l’architecture d’information. Est-ce dû à un manque de compréhension de son principe et de sa représentation sous forme de diagrammes ou tout simplement à cause de son aspect « intermédiaire » entre les idées et les concepts abstraits de la stratégie et les wireframes qui sont d’ordre plus concret et plus près du produit final.

Ce qu’il faut savoir c’est que c’est justement à cause de son rôle de « pont » entre l’abstrait et le concret, que l’architecture d’information est précieuse et indispensable à la conception de tout projet. Sans elle, il est impossible de concevoir un produit ayant la capacité de bien représenter les objectifs de l’entreprise et de combler avec précision les besoins des utilisateurs finaux. Il est impossible de penser qu’un produit puisse évoluer dans le temps sans une structure bien pensée.

La conception d’une architecture d’information s’applique à n’importe quel produit interactif, un site Web, une application de télé interactive ou mobile, etc. Ce sont tous des produits dynamiques dont le contenu et les fonctionnalités offerts évoluent avec le temps. Donc, la structure de base de l’architecture d’information doit permettre une croissance sans nécessairement impliquer des changements majeurs ayant un impact sur les utilisateurs finaux et les responsables des contenus ou des produits. Il faut se rappeler qu’un des plus grands avantages d’une bonne architecture d’information c’est le fait qu’elle rende plus facile l’utilisation du produit final tant auprès des utilisateurs et qu’aux responsables des produits.

Le temps qu’il faut dédier à la définition de l’architecture d’information ne doit jamais être vu comme une perte de temps, mais plutôt comme une étape nécessaire et fondamentale pour créer un produit de qualité projeté sur un court et un long terme.

Dans notre domaine, il est important que nos clients comprennent notre processus de travail et les étapes par lesquelles nous passons avant de livrer le résultat d’un projet. C’est important, parce qu’il faut qu’ils croient à ce que nous faisons et qu’ils soient à l’aise pour collaborer tout au long de l’évolution du projet. Nous ne nous enfermons pas dans nos bureaux pour en sortir quelques mois plus tard comme par magie avec des livrables. Le travail est toujours fait en collaboration avec le client et il est crucial qu’aucune étape ne soit oubliée ou négligée.

Donc, voici un bon outil : The Elements of User Experience, de Jesse James Garrett, un livre paru en 2002, qui explique de façon simple et succincte les étapes d’un projet pour bâtir une bonne expérience utilisateur. Ce livre ne parle pas de détails techniques et, ne nous permet certainement pas d’acquérir toute la connaissance dont nous avons besoin pour devenir un expert en design centré utilisateur, mais ce n’est pas son objectif. Ce qu’il offre, c’est un modèle facile à comprendre qui permet d’établir une communication claire entre le professionnel de l’utilisabilité et son client. Il présente une terminologie organisée de façon à réduire l’ambiguïté et à fixer un point commun de compréhension. Le diagramme qui forme le point de départ du livre résume le contenu et sert de guide permanent pour nous accompagner tout au long d’un projet.

Un très bon livre, de lecture rapide et agréable, dont la valeur réside en une série d’explications claires et simples des étapes d’un projet et des raisons pour lesquelles on ne doit pas chercher simplement des raccourcis pendant le développement d’un produit - situation qui arrive avec une fréquence relativement élevée.

Je vous le conseille vivement !

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.

Tous les professionnels, qu’importe leur domaine, cherchent des moments de bonheur. Ce sont ces moments qui nous font rappeler les raisons pour lesquelles on a choisi un certain métier.

J’ai réalisé, il n’y a pas longtemps, qu’il y a deux de ces moments pour moi, qui font le bonheur de l’ergonome des interfaces que je suis.

Le premier, c’est lorsqu’on conçoit un objet ou un élément dans une interface qui est tout de suite compris et apprécié par les utilisateurs lors des tests d’utilisabilité. C’est très gratifiant de voir qu’on a été capable de comprendre le modèle mental des utilisateurs.

Le deuxième, c’est exactement la situation inverse. Lorsqu’on fait un test et que les utilisateurs trouvent que ce qu’on a conçu ne fait pas de sens et nous suggèrent des bonnes solutions, ça nous allume et nous rappelle que nous sommes les concepteurs et non les utilisateurs finaux du produit.

Et ça c’est la leçon la plus importante pour ceux qui envisagent travailler dans ce domaine.