Query Tracking System: une étude de cas

D’une manière générale, Query Tracking System, ou QTS comme il a été abrégé, était un projet lié au secteur des voyages sur lequel nous avons travaillé aux débuts de Visionär mais les travaux de l’interface utilisateur et du parcours utilisateur pour l’application ont été réalisés en grande majorité par l’une des équipes de Visionär. Il est important pour nous de se référer aux quelques applications sur lesquelles nous avons travaillé et partager nos expériences afin de réfléchir sur l’importance de regarder les projets digitaux selon le point de vue de l’utilisateur. Dans le cas de QTS, le projet a eu un impact sur des dizaines de milliers de transactions et sur les revenus chaque année.

QTS était un système dont le but était de régler le problème de l’administration complexe au sein d’une entreprise européenne où les requêtes avait pris énormément de retard.

Les agences de voyages ou travel management companies (TMC), ainsi que les travel managers au sein des agences, reçoivent de nombreuses requêtes chaque jour. Ces requêtes peuvent par exemple avoir pour sujet les voyages impayés, les mauvais tarifs pour certains itinéraires, les promotions non appliqués dans les hôtels et les demandes de remboursement. Et la liste n’est pas finie.

QTS était un système dont le but était de régler le problème de l’administration complexe au sein d’une entreprise européenne où les requêtes avait pris énormément de retard. Ce retard représentant des transactions d’une valeur avoisinant le demi-million de francs à l’époque.

En réalité, QTS était un projet assez difficile à prendre en main. Par exemple, deux développeurs ont travaillé sur le projet avant qu’il ne nous soit transmis et avec déjà tenté de nombreuses solutions. Il y avait une réelle inquiétude de ne pas savoir si le projet pourrait être achevé ou non.

A aucun moment les aptitudes des développeurs n’ont été mises en doute. A vrai dire, leur expérience ne faisait l’ombre d’un doute. Cependant, les développeurs codaient selon leur point de vue sur ce que l’application devait faire plutôt que ce que les utilisateurs avait besoin. C’est un problème assez commun, l’accent est mis sur les critères de fonctionnalité et l’utilisateur fini par être au second plan. Naturellement, que l’utilisateur soit au second plan signifie qu’il doit lui même interpréter ce que l’application essaie de faire, ce qui mène à de la frustration et une baisse d’envie d’utiliser l’application. Et tout ça parce que le projet n’est pas développé en gardant l’utilisateur en tête. Les plans de projet peuvent évincer la valeur des recherches et des procédés UX qui sont là pour clarifier comment devraient être développés l’UI et l’UX selon les besoins des utilisateurs. Ces procédés sont souvent vitaux et permettent aux utilisateurs d’accomplir leurs objectifs.

Une fois que nous avons rejoint le projet, l’accent a été mis sur ce que l’utilisateur doit voir afin d’arriver à son but.

Une fois que nous avons rejoint le projet, l’accent a été mis sur ce que l’utilisateur doit voir afin d’arriver à son but. Des analyses de tâches ont été conduites (étudier les procédés et parcours nécessaires à l’utilisateur pour voyager). En plus de cela, notre architecte a préparé un brouillon de plan de site (une vue d’ensemble de l’application) et l’a amélioré suite à des entrevues avec les parties prenantes et les équipes internes qui allaient être les utilisateurs principaux.

Enfin, le travail s’est tourné vers l’adaptation de l’UI, en établissant un guide de style assez simple concentré sur la clarté, la simplicité et la facilité d’utilisation. Les recherches ont été utilisées pour influencer la navigation, la manière dont les utilisateurs se connecteraient à l’application, ainsi que où les utilisateurs arriveraient une fois leur requête terminée. Cela nous a permis de minimiser le nombre de pages à parcourir par l’utilisateur et identifier des informations contextuelles qui devaient être afficher plus haut dans l’architecture du système pour permettre à l’utilisateur de gagner du temps. De plus, le temps passé avec les utilisateurs pour comprendre leur point de vue sur les composants de l’UI n’a pas eu de prix, cela a permis aux utilisateurs de gagner du temps à l’utilisation car le fonctionnement était clair. Nous avons accompli cela à une époque où l’intégration n’était pas appréciée tel qu’elle l’est aujourd’hui.

Au bout du compte, la grande majorité de l’application était concentrée sur le service de messagerie instantanée. Comme WhatsApp ou BBM, le service avait un outil de fichiers joints et de sujets basés sur le type de requête. Différents acteurs du procédés de gestion des requêtes avaient besoin de savoir le statut de chaque requête et son importance, afin de determiner quelle action accomplir. En plus de cela, il fallait résoudre le problème du temps d’attente des requêtes dans l’application et que des alertes soient créées. Tout cela a été réglé et implanté dans un interface où les managers et les équipes pourraient voir les requêtes en attentes et celles avec des références, leur permettant ainsi de changer les statuts de priorité et les réponses.

Ce projet a vraiment été intéressant. Nous avons réussi à rattraper le temps perdu lors des problèmes avec l’UI et à satisfaire les besoins des développeurs ainsi que répondre aux attentes de l’entreprise.