Linkurious
| Capture d'écran de l'actuel "Alert Creation"
Linkurious est une bibliothèque JavaScript ainsi qu'une application conçue pour les utilisateurs techniques et les data scientists.
Actuellement, l’application propose une fonctionnalité appelée « Alert », qui permet d’automatiser la détection de schémas.
Voici comment cela fonctionne :
L’utilisateur crée une alerte en définissant des règles de détection.
Lorsqu’un schéma est détecté, l’alerte génère automatiquement des cas.
Ces cas sont ensuite traités par des enquêteurs ou des analystes.
| Les tâches qui m'ont été donnés :
pour équilibrer les améliorations avec contraintes
L’un des éléments les plus importants à éviter est le biais de survivant.
Le risque : perturber excessivement le parcours utilisateur pour ceux qui n’ont aucun problème avec la fonctionnalité actuelle d’Alert.
Il est important de comprendre, en premier lieu, pourquoi certaines personnes parviennent à l’utiliser.
Peut-être que l’interaction n’est pas courante ?
Si d’autres utilisateurs y parviennent, quels types d’applications utilisent-ils également ?
Quel type de support utilisent-ils ?
Quel est l’objectif de leur utilisation ? Est-ce conforme à l’usage initialement prévu de la fonctionnalité ?
| Outils
| Le Figjam de l'userflow actuel pour l'alert
Pour ce type de cas, l’utilisation de données est très importante pour comprendre où se situent les problèmes.
Quel type de données recherchons-nous ? Principalement des retours utilisateurs, mais aussi les échecs de création d’alertes.
Ce type de données nous aidera à éviter le biais de survivant.
Cependant, il est important de garder à l’esprit que le contexte est essentiel pour bien comprendre.
Le risque : à ce stade, interroger directement un utilisateur peut nous aveugler sur les vrais besoins, ce qui peut mener à des améliorations qui perturbent les utilisateurs actuels.
L’un des éléments les plus importants est de limiter le travail de développement.
Cela permettra de réduire le temps passé sur cette modification.
Prioriser les « quick-fix / quick-win »
Quelles sont les limitations techniques dans ce cas ? Quel type de librairies pourrait être impacté ?
Ce projet a-t-il une deadline ? Comment devons-nous le prioriser ?
Mais attention à l'endettement technique !
L’idée est maintenant de commencer à chercher où se situe principalement le problème.
D’après les données que nous avons, nous pouvons comprendre que les principaux problèmes viennent de là. On peut voir ici que deux des principaux problèmes sont :
La priorisation de l’information
Les champs de saisie pour le calcul des requêtes
Le pré-traitement des données
Cette version se concentre principalement sur l’idée d’une modification à faible effort. Les principaux changements visent donc à mieux hiérarchiser les informations fournies à l’utilisateur.
Cependant, elle a également été pensée pour faciliter une transition entre la version originale et la version 2, qui sera plus complète et définitive.
Gardez à l’esprit qu’il s’agit d’un wireframe basique, et non d’une version finale de la solution.
Cette version est une amélioration majeure par rapport à l’utilisation actuelle de la page. Le principal problème lié à la hiérarchisation de l’information est qu’elle exige que l’utilisateur remplisse tous les champs sur une seule page.
J’ai donc décidé de modifier cela en m’inspirant de l’interface de YouTube lors du téléversement d’une vidéo.
Cela signifie que les informations sont présentées progressivement, en cliquant sur « Suivant ». Les différentes informations à renseigner sont affichées via un système d'étapes (stepper).
Conclusions
Pour la suite ✨
Cette étude de cas a été une expérience d’apprentissage précieuse qui a approfondi ma compréhension de l’importance cruciale des données dans le processus de design UX. Il a mis en évidence que, sans données réelles ou retours utilisateurs, les designers peuvent facilement tomber dans le piège du biais de survie, en faisant des suppositions basées sur des informations limitées ou trompeuses.
Cela peut finalement conduire à des décisions de design qui ne répondent pas aux véritables besoins des utilisateurs et qui échouent à résoudre les bons problèmes.
Bien que je n’aie pas été retenu par Linkurious suite à cet exercice, je suis reconnaissant qu’ils m’aient donné l’opportunité de travailler sur un problème concret et de pouvoir présenter cette étude de cas dans mon portfolio.
Prochaines Étapes 👣
Fort de cette expérience, je prévois d’approfondir mes compétences en design basé sur les données et d’explorer des problématiques plus complexes.
Je souhaite collaborer étroitement avec les utilisateurs et les développeurs pour concevoir des solutions ancrées dans les besoins réels.
Ce projet a renforcé mon engagement envers un design réfléchi et centré sur l’utilisateur à chaque étape du processus.