En pratique, une décision aussi importante que la refonte d'un système d'information, qu'il s'agisse d'un portail d'entreprise, d'un site d'auto-assistance (agence virtuelle) ou d'un système collaboratif, est une décision commerciale qui peut avoir de multiples fondements.
Dans la conception de l'expérience utilisateur, les changements d'interface sont récurrents, tout comme les processus de refonte.
Or, un système peut être repensé non seulement parce qu'il présente des problèmes d'utilisabilité ou qu'il lui manque des fonctionnalités, mais aussi pour des raisons de sécurité, de performance, pour faciliter les maintenances futures et augmenter la fiabilité [1].
L'évaluation d'un système collaboratif présente une complexité supplémentaire par rapport au processus d'évaluation d'un système avec lequel chaque utilisateur interagit de manière indépendante. Certaines méthodes d'évaluation utilisent [2] :
- Des heuristiques,
- des scénarios,
- des modèles spécifiques ou des frameworks,
- des modèles basés sur des tâches de groupe, etc.
Dans le contexte d'un système collaboratif, la "tâche" typique que nous utilisons pour tester un protocole avec un utilisateur doit être modifiée pour prendre en compte le contexte du travail d'équipe [2].
Si vous faites partie d'une équipe de conception ou de développement qui planifie la refonte d'un système collaboratif, vous disposez d'au moins quatre sources complémentaires de solutions d'évaluation, que vous pouvez utiliser en fonction du contexte du projet :
- Le test rapide à faible coût, type test guérilla,
- l'évaluation par des experts utilisant des heuristiques et/ou des scénarios,
- les méthodes basées sur la recherche ethnographique,
- d'autres méthodes spécifiques.
Selon Guy [2], contrairement à l'évaluation classique (lorsqu'un seul utilisateur interagit avec le système) pour les systèmes collaboratifs, il est fondamental d'avoir une vision holistique, de développer la modélisation, l'abstraction et la représentativité.
Il est évident que rien de tout cela ne peut être basé sur un seul format d'évaluation et que pour avoir une vision holistique, il est nécessaire de très bien comprendre les relations qui se nouent entre les personnes et de connaître le contexte de travail collaboratif, en plus d'évaluer un système pour le redessiner.
Sans aucun doute, Google Drive est l'un des produits phares de Google, c'est pourquoi l'amélioration continue est à la fois une priorité et un territoire sensible pour ses concepteurs.
Lors de la mise en œuvre de changements dans un système avec autant d'utilisateurs, il est essentiel de garder le contrôle et d'éviter "l'aversion au changement", ou la résistance des utilisateurs fréquents à la modification d'une interface.
Dans « Minimizing change aversion for the Google Drive launch » [3], un travail présenté à CHI 2013, l'équipe de Google explique l'importance de prendre en compte la courbe d'apprentissage dans l'utilisation d'un système.
En particulier, le fait d'être habitué à un système fait que même face à un changement qui devrait améliorer son expérience, l'utilisateur familiarisé peut présenter une forte résistance au changement.
Dans ce sens, l'équipe de conception de Google s'appuie sur des théories psychologiques, explore les schémas d'aversion au changement et analyse les données des lancements de conceptions précédentes pour préparer la nouvelle mise en production d'un changement d'interface.
En conséquence, ils proposent le cadre de travail suivant, qui peut certainement être très utile pour toute équipe travaillant sur la refonte d'un système :
- Planifier les étapes du lancement.
- Évaluer l'impact sur l'utilisateur avant le lancement.
- Préparer les utilisateurs au changement planifié.
- Expliquer les avantages du changement.
- Offrir un soutien à la transition et un support.
- Laisser l'utilisateur passer de la nouvelle version à l'ancienne. Note : Ce point est probablement l'un des plus complexes car il est difficile de faire cohabiter deux interfaces, d'autant plus s'il y a des changements technologiques en arrière-plan.
- Surveiller et gérer le changement au fil du temps.
- Laisser les utilisateurs envoyer des commentaires directement.
- Gérer rapidement les problèmes des utilisateurs.
- Informer l'utilisateur des améliorations apportées.
Ces conseils me semblent fondamentaux pour toute équipe qui planifie un changement majeur dans une interface. Dans mon travail chez Movistar et Sura, la question constante était : « Comment améliorer l'expérience de tous sans générer de frustrations pour certains ? »
Avec cela, il y avait évidemment la question de la satisfaction. À cet égard, je me souviens aussi de la problématique soulevée par les dirigeants d'un système ERP qui nous ont dit qu'un simple changement de bouton, qui était censé simplifier l'accès à l'information pour les responsables du service client d'une entreprise cliente, pourrait entraîner une augmentation substantielle des appels au service d'assistance.
Pourquoi ? Les responsables étaient habitués à faire 5 clics pour arriver à un écran et le faisaient de manière presque robotique.
En changeant l'interface et en rendant la même information disponible en 4 clics, les responsables se perdaient et ne trouvaient plus l'information. Frustrés, ils appelaient le service d'assistance de la plateforme.
Maintenant, la question est : devriez-vous faire une liste de contrôle, coller ces 10 conseils sur votre bureau et les suivre à la lettre ? Cela dépend.
Google a tendance à concevoir des services exceptionnels et son équipe a clairement l'expérience pour le faire. Dans la réalité locale, en tant qu'utilisateur et en tant que manager, on se retrouve souvent avec des services numériques obsolètes qui ont définitivement besoin d'être améliorés ou littéralement repensés et reconsidérés à partir de zéro.
Dans les cas très extrêmes, l'écart est si grand entre ce qui existe et ce que l'utilisateur attend ou la moyenne de ce que nous sommes habitués à voir sur le marché, qu'appliquer à la lettre chacune des étapes serait probablement inutile.
Je viens de recevoir un e-mail d'une entreprise financière annonçant un changement dans son interface numérique. En tant qu'utilisatrice, j'aurais aimé voir les changements en premier.
Pour un système qui n'a pas connu d'améliorations concrètes depuis 5 à 7 ans ou plus, il vaut mieux investir dans les tests et la refonte que dans des campagnes de communication pour expliquer ce qui va changer, et qui aurait dû changer il y a 5 ans.
Au contraire, lorsqu'on constate une préoccupation constante pour l'expérience utilisateur et que l'on perçoit des changements mineurs de manière récurrente, il est appréciable de recevoir une communication qui annonce une nouvelle fonctionnalité ou une autre qui sera supprimée.
Avez-vous participé à des projets de refonte de systèmes collaboratifs ? Racontez-nous votre expérience.
[1] El-Khawaga, G. H., Galal Hassan Galal-Edeen, G.H., Riad, A.M. (2013). Quality Attributes and Software Architectures Emerging Through Agile Development: Pursuit or Overlooking? International Journal of Software Engineering (IJSE), Volume (4) : Issue (1).
[2] Guy, E. (2005). “…real, concrete facts about what works …”: Integrating Evaluation and Design Through Patterns. Proceedings of GROUP’05, November 6–9, 2005, Sanibel Island, Florida, USA. Copyright 2005 ACM.
[3] Sedley, A.Müller, H. (2013). Minimizing change aversion for the Google Drive launch. En Proceedings: CHI’13 Extended Abstracts on Human Factors in Computing Systems, ACM, New York, NY, USA(2013), pp. 2351-2354.
Par 
![Convaincre son boss d'investir en UX [2021]](/content-images/331a6776-invertir-usabilidad-ux.jpg)
