LOG2420   LOG2420, Analyse et conception d'interfaces utilisateur
Automne 2021

L'exercice Émilie -- Énoncé (inactif pour l'automne 2021, consultez LOG2420 sur Moodle)

Il y a quelques années, Bell a lancé le service à la clientèle basé sur la reconnaissance vocale. L'exercice suivant consiste à établir les exigences utilisateur.

Appel

Un exemple de dialogue

Un plan potentiel

Un exemple partiel de plan de développement centré-utilisateur. L'exemple n'est pas complet mais vise à illustrer les principes généraux de la conception centrée-utilisateur dans un contexte concret.

Une des premières étapes consiste à établir combien d'itérations ou de phases seront nécessaires. Plus un projet est de grande envergure et risqué, plus il y aura de phases et de jalons permettant de confirmer qu'on avance dans la bonne direction. Pour ce projet, on pourrait spécifier trois phases.

Phase 1 -- contexte d'utilisation et conception préliminaire

  1. Objectifs organisationnels
    1. Objectifs d'affaire
      • Diminution du temps de réponse des agents au service à la clientèle de 20%
      • Augmentation du nombre d'appels traité par agent au centre par 30% (10% des appels se concluant sans intervention humaine)
      • Récupération de l'investissement en 5 ans
    2. Contexte actuel et situation visée

      Une description de ces contextes...

    3. Intervenants, parties prenantes (stakeholders)
      • Direction du centre d'appels
      • Direction du soutien technique
      • Syndicat des agents
      • Équipe de développement
      • Direction générale
  2. Utilisateurs, tâches et contexte d'utilisation

    Recueil d'information autour des points suivants.

    1. Utilisateurs
      1. Clients utilisateurs
        • Profil démographique et linguistique
        • Fréquence d'utilisation
        • Éducation; familiarité avec les technologies, notamment la reconnaissance vocale
      2. Téléphonistes
        • À quelle information de l'échange auront-ils accès?
        • Expérience avec l'ordinateur
      3. Techniciens
        • À quelle information de l'échange auront-ils accès?
        • Comment feront-ils le suivi avec le système?
        • Expérience avec l'ordinateur
    2. Tâches (clients, téléphonistes, techniciens)
      1. Fréquence des raisons d'appels
      2. Fréquence des tâches
      3. Décomposition des tâches et identification de l'information utilisée
      4. Documentation du vocabulaire employé par les clients (clients)
    3. Contexte d'utilisation
      1. Qualité de la communication et bruit ambiant
      2. Situations d'appel (urgences, temps de réparation exigé/attendu, appel d'un portable)
      3. Charge technique
        • Achalandage
        • Capacités de traitement
        • Performance du matériel (taux de reconnaissance)
    4. Analyse des systèmes similaires
    5. Analyse du taux de reconnaissance attendu
    6. Analyse coût-bénéfice

    Les activités qui permettent d'obtenir cette information sont, par exemple

    • Observations des téléphonistes et analyse des enregistrements; peut-être aussi observation et écoute d'utilisateurs des systèmes similaires/concurrents
    • Analyse de tâche et de l'allocation
    • Groupes de discussion et séances de remues méninges
      • auprès de ...
    • Interviews et analyse de la documentation
    • Sondage auprès de ceux qui ont eu recours au service
  3. Exigences
    • Il faut documenter les exigences à un premier niveau de détails suite à aux activités de la phase 1
    • Par exemple, on peut, en fonction des objectifs d'affaire et de l'analyse du contexte d'utilisation, déjà établir le taux acceptable d'erreurs de la reconnaissance vocale, le temps que devrait prendre une tâche dans un scénario spécifique, le nombre de clients qui doivent résoudre le problème sans recours à un agent, etc.
  4. Premier concepts d'interface
    • Définition d'un scénario potentiel
    • Activité : Groupe de discussion et de remue-méninges pour proposer des concepts
    • Activité : tests avec la technique du Magicien d'Oz et avec des utilisateurs représentatifs; les tests peuvent inclure plusieurs concepts à l'étude car peu d'efforts sont requis pour créer le prototype
    • L'analyse du taux de reconnaissance attendue peut aussi impliquer des activités de tests système afin d'établir les balises de ce qui est faisable et du taux d'erreurs attendu
    • Choix du concept (conception générale). On entend par "concept" les principes de bases du mode d'interaction, par exemple :
      • Le système s'adaptera en fonction de l'historique du compte. Il mémorisera les dernières raisons d'appel pour un dossier et raccourcira les échanges sur cette base.
      • Le système utilisera le même mode que la RVI (réponse vocale interactive) avec des choix 1, 2, 3, ..., mais il permettra de saisir vocalement le numéro en plus du mode touche (actuellement on utilise des mots clés plutôt que des chiffres).
      • Le premier niveau sera le seul sur lequel nous travaillerons à une reconnaissance complexe avec un vocabulaire élaboré et une reconnaissance pour un choix étendu de dizaines d'options. Nous miserons sur un apprentissage de la part du client afin d'arriver rapidement à une solution. Cet apprentissage se fera naturellement par l'échange avec Émilie.
      • Nous utiliserons une approche binaire avec oui et non comme seule réponse possible dans la grande majorité des cas.
      Le concept est donc un ensemble de lignes directrice de conception.
    • Première validation des concepts

      Comme les options sont très différentes, on peut tenter quelques expériences avec les concepts évoqués afin de déterminer ceux qui sont les plus prometteurs. Selon le temps et les ressources disponibles, on pourrait même aller de l'avant avec plusieurs maquettes, ou des expériences du magicien d'Oz, jusqu'à ce qu'on soit plus confiant qu'une approche est meilleure que l'autre.

      On itérera ainsi pour raffiner et valider les exigences, éliminer et raffiner les concepts pour en retenir un qui sera prototypé en phase 2.

Phase 2 -- Prototypage et tests utilisateurs

La seconde phase permettra de préciser les exigences avec un prototype plus réaliste et un meilleure compréhension et définition du contexte d'utilisation et technologique. On présume que la première phase a permis le choix d'une conception générale.

De plus, comme il s'agit, dans ce cas spécifique, d'un type de projet peu répandu et à la fine pointe des possibilités technologiques, cette phase devrait établir les critères pour décider d'aller ou non de l'avant.

  1. Plan général
    1. Définition des tâches qui peuvent être implantées et de la répartition (qu'est-ce qui sera automatisé)
    2. Définition de scénarios d'utilisation
    3. Développement d'un prototype en partie fonctionnel
    4. Tests utilisateurs
    5. Raffinement des exigences

On peut imaginer deux itérations à cette étape où les exigences, les tâches, les contraintes, etc., seront progressivement raffinées. On obtiendra une meilleure idée du potentiel du système pour en venir à une décision à savoir si on passe à la prochaine phase et dans quelle mesure on peut atteindre les exigences.

Phase 3 -- Exigences détaillées et documents d'analyse

La troisième phase permet repose sur une certaine assurance que le système est faisable et peut rencontrer les objectifs du projet, ou du moins une partie d'entre eux. Une planification détaillée des activités s'en suit. Il serait difficile de faire la planification détaillée de cette phase sans avoir les résultats des premières phases car le système comporte un grand nombre d'incertitude et plusieurs exigences ne peuvent être définies d'emblée. C'est la nature nouvelle du projet qui implique cette incertitude et d'autres projets pourraient commencer avec des exigences détaillées. Par exemple, la refonte du système Émilie ne nécessiterait pas les mêmes étapes. On viserait plutôt des améliorations suite aux expériences et commentaires retenus. Les activités seraient elles aussi différentes, notamment un suivi après déploiement des problèmes rencontrés, un sondage de satisfaction, etc.