Azot, l’analytics d’UX

Azot, l’analytics d’UX

Le contexte

Nous avons compris très rapidement que l’expérience de l’utilisateur (UX) conditionnait sa fidélité au sein d’une application mobile. En tant que tout product owner, cette fidélité est le graal recherché dans toute stratégie mobile.

En 2015, les outils sur le marché étaient en revanche principalement centrés sur l’analyse de performance des campagnes d’acquisition d’utilisateurs (AppsFlyer, MixPanel, Google Analytics) ou sur la performance technique des serveurs ou des applications (Crashlytics). Ainsi, nous avons entrepris de concevoir un outil d’analyse d’expérience utilisateur.

Azot est donc né de ce besoin de mise en place de métriques pour mesurer l’UX dans une application mobile afin d’accompagner son propriétaire dans l’amélioration de son produit.

Qu’est-ce que l’Expérience Utilisateur ?

L’UX est un vaste domaine. Elle démarre dès les premiers contacts de l’utilisateur avec la marque, se poursuit pendant l’utilisation du produit et ne s’arrête jamais.

Le mobile est en cela particulier qu’il existe un parc hétéroclite de périphériques et versions de systèmes d’exploitation. Plusieurs contraintes sont donc imposées au product owner pour garantir une expérience optimale :

– Son application doit se comporter de la même manière sur n’importe quel périphérique

– Son application doit s’afficher de la même manière, indépendamment de la taille et de la typologie des écrans

– Son application doit s’adapter à l’utilisateur Android et l’utilisateur Apple. Ne serait-ce par la logique de navigation (1 bouton sous Apple, 3 boutons sous Android)

– Les besoins des utilisateurs étant de plus en plus complexes (paiement en ligne, multimédia, reconnaissances faciales, synthèses vocales, E-Learning, sécurité) entraînent un besoin de simplification extrême du produit.

– Le caractère volatile des mobinautes allié à un nombre important d’applications pour les mêmes besoins, obligent le Product Owner à se concentrer sur la réalisation d’un produit de qualité forte.

Dans notre cas, nous avons défini la mesure de l’UX dans une application mobile par la mesure du niveau de frustration de l’utilisateur durant sa navigation.

Non content de pouvoir mesurer la frustration de l’utilisateur sur une interface, nous souhaitions pouvoir modifier à la volée cette interface en fonction du comportement, pour garder un niveau de frustration au plus bas.

Comment l’avons-nous mesuré?

En nous inspirant de la littérature, nous avons cherché dans les données d’utilisation, quels étaient les comportements des utilisateurs dans une application qui pouvaient être extraits et regroupés dans un même segment. Cette recherche est opérée en croisant les analyses comportementales et les techniques de Big Data. Cette segmentation est la base de la compréhension des utilisateurs et de leurs types d’interactions avec l’application. Elle est nécessaire pour pouvoir bâtir des modèles décisionnels qui ne soient pas noyés dans la masse et dans le bruit des données brutes. Mais elle peut aussi être utile au Product Owner en tant que tel pour lui permettre d’explorer les profils d’interaction principaux avec son application. Pour accomplir ceci, nous avons cherché un processus d’extraction de ces données et une interprétation par la machine qui se voudra versatile.

En cela, à travers l’utilisation de méthodes d’apprentissage comme celles citées précédemment, la machine devait donc être en mesure d’améliorer son niveau de segmentation pour tous les types d’applications mobiles, et de supprimer les comportements parasites.

Nous avons identifié les comportements qui correspondent à une mauvaise compréhension de l’interface ou à une frustration, et avons mis en place une méthode permettant de les détecter au sein des profils d’utilisation.

Notre enjeu principal était de proposer un format de visualisation de ces résultats de manière intuitive pour les utilisateurs d’Azot. Une fois les groupes d’utilisateurs et les patterns de navigation identifiés, nous avons injecté les modifications possibles de l’interface. Nous pouvions donc faire de l’AB Testing en temps réel, dans une application mobile native. L’interface évoluerait constamment, en fonction de l’identification dynamique des comportements des utilisateurs.

Les premiers résultats

Notre ambition était de réaliser un produit autonome qui puisse s’installer et être fonctionnel uniquement au travers quelques lignes de code. Nous avons oublié, dans notre conception la variabilité des méthodes de développement de chaque développeur. Il en a résulté en un produit complexe à intégrer pour n’importe quel quidam non rompu aux méthodes et habitudes de développement de AppStud.

Nous avons fait le choix de retirer le produit à usage du public et de le conserver pour nos clients privilégiés.