En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies pour vous proposer des offres adaptées à vos centres d'intérêt, recueillir des données de statistiques et permettre le partage de pages sur les réseaux sociaux.
  • Accueil
  • Blog
  • Comment nous utilisons le Machine Learning et le Big Data pour améliorer l’Expérience Utilisateur sur Mobile

Comment nous utilisons le Machine Learning et le Big Data pour améliorer l’Expérience Utilisateur sur Mobile

0%
Temps de lecture : 10 minutes

Après avoir franchi le cap des 5 000 téléchargements de notre dernier livre blanc « L’UX Mobile dans un contexte de Lean Agile », nous avons souhaité exposer notre méthodologie d’analyse d’Expérience Utilisateur (UX) au travers le Machine Learning et le Big Data.

1. Un besoin croissant d’analyse d’UX

La concurrence sur les stores a inversé la tendance entre apps et utilisateurs. Lorsqu’en 2010, Apple annonçait « Si vous cherchez cela, il y a une application pour ça », aujourd’hui si vous cherchez cela, il y a des dizaines d’applications pour ça. L’utilisateur mobile est désormais plus volatile et la pression est portée par le product owner qui se doit de concevoir un produit fédérateur.

Outre la création d’un produit utile, les challenges portés par le product owner sont donc multiples sur le plan de l’expérience vécue par l’utilisateur:

  • Il doit tenir compte des spécificités propres à chaque périphérique mobile,
  • Son application doit s’adapter à 2 typologies d’utilisateurs différents: Android et Apple.
  • Les habitudes des utilisateurs entraînent des spécifications techniques de plus en plus complexes (paiement en ligne, multimédia, reconnaissance faciale, synthèse vocale, sécurité). Cette complexité entraîne un besoin de simplification extrême du produit.
  • Une population d’utilisateurs toujours plus hétérogène, tant en terme d’âge que de maîtrise des technologies.

Les outils d’analyse actuellement sur le marché étant principalement centrés sur le tracking CRM, nous avons entrepris depuis bientôt un an de concevoir un outil d’analyse d’expérience utilisateur que nous utilisons dans les apps que nous développons, afin d’accompagner le product owner dans l’amélioration continue de son produit.

Exemple d’une application BtoC : des profils d’utilisateurs imprévus

Lors de la conception de l’application d’un aéroport, le product owner nous avait spécifié que celle ci devait être à destination du voyageur fréquent qui l’utiliserait lors de son arrivée sur site. Quarantenaire, Business Man/Woman, pressé. L’interface doit donc être pensée pour afficher rapidement l’information et mettre en avant des fonctionnalités comme le Wifi automatique ou la géolocalisation indoor de sa place de parking.

Nous avons donc pensé l’application selon ces spécifications et y avons embarqué Azot, notre outil d’analyse d’UX. Nous avons alors pu observer que le comportement des utilisateurs n’était pas limité à ce qui était prévu. En effet, il est apparu que les voyageurs utilisent souvent l’application avant leur vol afin d’identifier le trafic et l’heure approximative d’arrivée. Mais un autre type d’utilisation est également apparu, il s’agit des chauffeurs de VTC et des taxis, afin de connaître les heures d’atterrissage des avions les plus remplis.

Ainsi il apparaît que pour une même application différents profils d’utilisateurs (mais surtout de comportements) se dessinent, et qu’ils sont souvent différents de ceux identifiés à l’origine. C’est ainsi qu’est apparue l’idée de segmenter les typologies d’utilisation d’une application mobile.

Exemple d’une application pour seniors : les limites de l’analyse traditionnelle

AppStud a également conçu une application mobile pour seniors. Pour être meilleurs, nous avons travaillé avec une agence d’UX qui a convié des utilisateurs appartenant à la  » cible »  dans leur lab.

Nous avons réalisé plusieurs interfaces digitales et les avons remis à ces futurs utilisateurs en leur demandant « d’utiliser l’application comme vous le feriez tranquillement chez vous ». Ces gens se savaient filmés, et malgré nos demandes, nous les voyions lire toutes les interfaces ou encore, prendre du temps pour choisir sur quel bouton appuyer.

Nous avons alors élaboré un petit dispositif qui permettait d’enregistrer les vidéos des navigations et retenté l’expérience, cette fois en transmettant l’application à des utilisateurs seniors non conviés pour l’expérimentation. Les modèles de navigations étaient alors très différents et les premières interactions intervenaient plus rapidement. Il y avait beaucoup plus de gestures liées à des incompréhensions de navigation que dans la phase de tests en lab.

Conclusion : L’analyse d’UX doit se faire dans un contexte « libre » pour l’utilisateur pour enlever toute pression liée au regard d’une tiers partie prenante dans le projet.

D’où l’intérêt d’observer (de manière anonyme) le comportement de chacun des utilisateurs de l’application.

Nous nous sommes rendus à l’évidence que l’analyse d’UX devait se faire :

  • Par itérations successives
  • En segmentant des comportements d’utilisateurs
  • Dans un contexte dans lequel l’utilisateur est à l’aise et ne se sent pas observé

Détermination des informations à analyser

Nous nous sommes donc lancés dans la création d’un logiciel SaaS autonome qui permettrait d’obtenir les informations suivantes :

  • Feedback automatique pour poser les bonnes questions à l’utilisateur pendant sa navigation
  • Gestures afin de connaître la grammaire gestuelle utilisée à chaque écran
  • Les permissions acceptées pour garantir une utilisation maximale de l’application.
  • Vidéo des sessions pour se mettre automatiquement « par-dessus l’épaule » des utilisateurs en cachant bien entendu les champs confidentiels
  • Réseau afin d’identifier les comportements de l’application en fonction de la couverture réseau.
  • Informations du téléphone (modèle, taille d’écran, mémoire, …)

L’objectif était alors de répondre à la question :

Est-ce que mes utilisateurs comprennent mon interface ?

Analyse des Gestures

Bon nombre de travaux ont été effectués depuis les 20 dernières années autour de l’analyse des clics dans un contexte de sites web E-Commerce. Le papier Advances in Clickstream Data Analysis in Marketing paru en Mars 2008, explique la notion de « clickstream » qui est l’analyse des clics et des mouvements de la souris des utilisateurs en ligne sur un site web.

Ces données permettent aux analystes de comprendre les comportements et choix faits par les individus.

Dans notre cas, la principale différence entre un site web et une application mobile est l’instauration d’une nouvelle grammaire gestuelle différente du web (double tap, l’appui long, le swipe, etc…), et une gestion de la présentation du contenu fortement contrainte par la faible taille de l’affichage.

Azot a pour ambition de transformer cet état de l’art pour le mobile en lieu et place du web classique. En effet, les premiers articles de littérature pour le domaine du web remontent à une vingtaine d’années, alors que la démocratisation de la plateforme mobile date d’à peine plus de 5 ans, ce qui implique que la littérature scientifique à ce sujet est aujourd’hui beaucoup moins fournie. Les différences technologiques entre les deux plateformes étant fortes, nous nous retrouvons aujourd’hui face à un besoin urgent de compléter la recherche existante. En effet, les clicks sont remplacés par des touch/swipes. De nouvelles interactions sont rajoutées : le double tap, le force touch, l’appui long. Il n’y a plus non plus, sur une interface mobile, d’analyse des mouvements de souris.

Cartes de chaleur

Des recherches plus récentes autour de l’interaction entre l’utilisateur et une interface digitale existent et datent de 2013. Dans le document Gesture Tracking and Recognition in Touchscreens Usability Testing, l’auteur présente l’intérêt de l’analyse des gestures dans l’étude de l’Utilisabilité.

Différentes définitions existent pour « l’Utilisabilité ». Ainsi la norme par exemple PN- EN ISO9241 la définit comme « la capacité pour un produit de permettre à l’utilisateur d’accomplir son but initial efficacement et avec satisfaction ».

L’objectif de l’analyse des gestures est de créer des tests d’utilisabilité. Les auteurs ont ainsi créé un outil qui leur permettait de générer des cartes de chaleur en fonction des endroits et du nombre d’itérations de l’interaction Homme – Interface, et ainsi d’identifier les zones les plus intéressantes d’une interface.

Cette fonctionnalité a été implémentée dans Azot et permet d’identifier les zones d’interactions (et donc d’intérêt) et de les associer à des gestures spécifiques pour valider de la compréhension de la grammaire gestuelle appliquée à cette zone.

2. Datamining et Profiling

L’intérêt du Datamining pour améliorer l’UX Mobile

Les études montrent donc qu’une interface comprise par l’utilisateur bénéficie de 20% de chances supplémentaires pour amener l’utilisateur à réaliser l’objectif fixé par le product owner.

Le problème principal vient du fait que traditionnellement la détermination du profil des utilisateurs est faite en leur posant des questions au travers d’un formulaire initial. Or un formulaire sur une interface mobile est anti-user-experience de par la nature même du périphérique (petit écran), le formulaire (nombre de questions important pour déterminer un profil précis) et l’utilisateur mobile lui-même (pressé).

Le papier de recherche Mining and Analysis of Clickstream Patterns (2009) insiste sur l’intérêt de segmenter grâce à un algorithme intelligent des poches d’utilisateurs en fonction de leurs différents comportements d’utilisation sur des pages web en récupérant les logs d’un serveur. Dans un contexte mobile, cette méthode permettrait d’améliorer l’expérience utilisateur au travers de techniques comme le morphing (Modification d’interface à la volée).

Dans notre cas, le principal challenge était d’identifier les profils d’utilisateurs sans le leur demander explicitement.

Application du datamining aux données de Azot

L’intérêt d’utiliser des méthodes statistiques pour analyser ces données est de s’émanciper des idées préconçues qui se forment naturellement pendant le design et la réalisation d’une application. En effet les différents acteurs de la réalisation d’une application ont forcément un avis non objectif sur leur application. Ils l’ont conçue pour répondre à un certain nombre d’usages bien définis, or le comportement des utilisateurs comprend une grande part d’imprévisibilité, qui peut donc mener à une fausse interprétation des données remontées par Azot. A contrario, les informations mises en évidence par des outils statistiques sont indépendantes de tout préjugé de par leur nature.

Cependant de simples statistiques descriptives ne suffisent pas toujours à briser ces préjugés, il est donc nécessaire d’utiliser des méthodes plus avancées.

Méthode employée

Rappelons que notre objectif est de mesurer la qualité de l’expérience utilisateur. Habituellement cette analyse se fait via des feedbacks des utilisateurs, ou encore via des études où l’on invite des utilisateurs à tester l’application tout en observant leurs réactions. Cependant ces études coûtent cher et sont souvent biaisées par le fait que (1) tous les profils d’utilisateurs ne sont pas amenés à témoigner, (2) ou que les témoignages sont faits après la navigation . D’où l’intérêt d’observer (de manière anonyme) le comportement de chacun des utilisateurs de l’application.

En considérant cet objectif, une méthode statistique intéressante est le clustering. Il s’agit tout simplement de regrouper des éléments en différents groupes selon leur ressemblance entre eux. Dans notre cas on s’intéresse à la façon dont les utilisateurs se comportent sur notre application, on cherche donc à regrouper les utilisateurs selon la façon dont ils utilisent l’application. Pour ce faire nous créons des groupes à partir des séquences de pages visitées lors d’une utilisation de l’application (une session).

L’intérêt du clustering est qu’il s’agit d’une méthode « non supervisée », c’est-à-dire qu’aucune intervention humaine n’est nécessaire (contrairement à d’autres méthodes qui requièrent de disposer en amont de données déjà triées). Ainsi il est réellement possible de s’abstraire des différents préjugés afin d’identifier pour chaque utilisateur son comportement, et ce de manière automatique.

Cependant les sessions remontées par Azot comportent plus d’informations que seulement les pages visitées. Il est donc également intéressant de mettre ces informations en perspective des différents « patterns de navigation » que nous avons précédemment obtenus. Ainsi avec une autre méthode statistique (l’Analyse Factorielle des Correspondances Multiples) et des tests statistiques d’hypothèses, il est possible d’extraire pour chaque groupe d’utilisateur différentes caractéristiques. Cela peut alors permettre au développeur de l’application de s’apercevoir par exemple que son application est plus ou moins facile à utiliser selon le modèle de téléphone utilisé, etc…

Résultats avec l’application de l’aéroport

A partir des sessions effectuées pendant une semaine sur cette application et remontées par Azot, on peut alors extraire les différentes séquences de pages visitées et les regrouper en différents groupes selon leur similarité. De plus une fois ces groupes de sessions obtenus, on peut observer les différentes caractéristiques de chaque groupe pour obtenir des informations de ce genre :

clustering-azot

Comme on peut voir sur l’exemple ci-dessus, on obtient un grand nombre d’informations qui vont nous permettre de mieux comprendre le comportement des utilisateurs. Ainsi on peut ici identifier 3 façons différentes d’utiliser l’application (il y a plus de classes en réalité, mais pour l’exemple celles-ci suffisent) :

  • La classe 0, qui est prépondérante (environ 60% des sessions), représente les utilisateurs utilisant l’application pour suivre les détails de leur vol. Il s’agit du comportement imaginé lors de la création de l’application, à quelques modifications près (par exemple l’utilisation des pages HOME et WIFI n’en fait pas partie).
  • La classe 1 (presque 30% des sessions) représente plutôt les personnes utilisant quasiment exclusivement la page HOME, afin de vérifier par exemple les temps d’attente aux contrôles de sécurité. Cette classe comprend également des personnes utilisant ponctuellement une autre page, comme TRAFICROUTIER. Cette classe met en évidence une utilisation bien spécifique de l’application : dans presque 1/3 des cas, l’utilisateur ne visite qu’une page. Il cherche donc une information bien précise et ne se préoccupe pas du reste.
  • Enfin la classe 2 (environ 7% des sessions) est typique des premières connexions à l’application : passage par les pages de tutoriel, création d’un compte (page LOGIN) et visionnage de quelques pages. On peut remarquer que ces sessions sont généralement longues, beaucoup de pages sont visitées. Cela met en évidence un comportement spécifique des utilisateurs lors de leur première connexion, qui vont avoir tendance à explorer l’application pour la découvrir. Ce comportement pourrait indiquer par exemple que le tutoriel n’est pas suffisant pour permettre aux utilisateurs de bien découvrir l’application.

Adaptation de la navigation

L’objectif final serait d’utiliser ces informations pour adapter la navigation à chaque utilisateur. En effet, pour un utilisateur donné, une fois que l’on a identifié son pattern de navigation type et les pages qu’il utilise de préférence, il serait alors possible de personnaliser la page d’accueil de manière à lui permettre d’accéder directement aux services qu’il a l’habitude d’utiliser, ce qui engendre naturellement une meilleure expérience utilisateur.

Dans le cas précédent, pour le pattern de navigation Home > Vols_Départ > VolDétail> Vols_Départ, on pourrait forcer l’application à « booter » sur la page Vols_Départ en évitant de passer par la page Home et donc réduire le nombre d’interactions de l’utilisateur avec l’interface.

Dans notre cas, nous évitons un écran en particulier, mais dans une application de type E-Commerce avec bon nombre d’écrans, il est très aisément envisageable d’étendre ce mode de fonctionnement aux Catégories de produits les plus souvent consultées afin d’amener automatiquement les utilisateurs vers telle ou telle catégorie.

Limites et axes de recherche à venir

Les premiers résultats indiquent que la partie fonctionnelle est bonne. Azot est en cours d’intégration dans plusieurs apps de E-Commerce. A ce niveau, nous sommes confrontés à deux grandes problématiques :

  • Comment savoir si c’est bien le même utilisateur qui utilise le périphérique pour consulter l’application ? Exemple d’une famille qui utilise une tablette commune.
  • Comment reconnaître le même utilisateur au sein de différents périphériques ? Exemple d’un même utilisateur qui utilise une même application depuis des smartphones ou tablettes différents. Cette problématique se contourne en revanche plus facilement que la précédente, compte tenu de la possibilité de « logguer » un comportement à un compte utilisateur. Elle est en revanche plus difficile lorsque l’application ne requiert aucune connexion.

Pistes de recherches

Nous avons souhaité dans un premier temps valider le fonctionnement sur une métrique en particulier qui sont les « patterns de navigation ».

Une première piste de recherche étudiée en ce moment consiste à intégrer les autres métriques que nous récupérons (gestures et zones de chaleur) afin d’enrichir la segmentation comportementale.

Vous souhaitez en savoir plus? Contactez nous !

Written by
Tech Enthusiast • Entrepreneur • Maker • Blogger
Laisser un commentaire