Itération de l’application mobile basée sur les données: voir le bois des arbres

  1. Home
  2. Captain Simple
  3. Détail de l'Article
Itération de l’application mobile basée sur les données: voir le bois des arbres


Imaginez un bûcheron qui veut abattre un arbre avec sa tronçonneuse. C’est une tâche assez simple et directe. Mais que faire si le bûcheron n’a jamais su qu’il pouvait allumer la tronçonneuse? Ou qu’il a coupé 1 000 arbres alors qu’il n’avait besoin que d’un seul arbre spécifique? Pas tout à fait le moyen idéal d’utiliser les outils à votre disposition.

Malheureusement, cette analogie peut facilement être traduite dans le monde des cycles d’itération des applications mobiles. De nombreux chefs de produit savent qu’ils ont besoin d’utiliser des données, et ils les utilisent – mais pas de manière idéale. Dans un monde qui ne tourne plus autour du «si» mais du «comment» nous utilisons les analyses et les données, que faut-il pour réduire le bruit, se concentrer sur ce qui est important et finir par créer des itérations d’applications mobiles supérieures?

Problèmes liés aux données

Les chefs de produit qui souhaitent être axés sur les données, mais ne savent pas exactement comment y parvenir, tombent généralement sous l’un ou plusieurs des pièges suivants lors de leur analyse pour l’itération des applications mobiles:

  1. Suivez tout ce qui est possible dans leur application sans avoir une idée exacte de la façon d’utiliser les données
  2. Passez énormément de temps à disséquer les données mais n’atteignez pas un niveau de confiance suffisamment élevé pour agir en conséquence
  3. Concentrer leurs efforts sur les mauvais éléments de données, passer moins de temps, mais finir avec des informations qui ne sont pas exactement idéales

C’est comme si notre exemple de bûcheron coupait tous les arbres, qu’ils leur soient utiles ou non. Ou s’il se concentrait sur tous les mauvais arbres, mauvaises herbes, sous-bois et plantes malades.

Parfois, les chefs de produit peuvent utiliser les mauvais outils pour comprendre les problèmes qu’ils rencontrent avec leur application. Par exemple, ils examinent simplement des données quantitatives telles que les taux de désinstallation et apportent des modifications à l’aveugle dans le prochain cycle d’itération des applications mobiles dans l’espoir que les taux s’améliorent. Même s’ils le faisaient, il n’y aurait aucun moyen de confirmer quel changement a provoqué l’amélioration. C’est comme essayer de couper un arbre sans allumer la tronçonneuse en premier.

Il se peut qu’ils rassemblent les bonnes données, mais sans objectif final clair ou cas d’utilisation à atteindre, ils finissent par utiliser ces données de la mauvaise manière, ou ne pas les utiliser du tout. Tous les arbres du monde ne signifieront pas grand-chose s’ils pourrissent dans la cour à bois. Les chefs de produit doivent savoir comment ils prévoient d’utiliser les données – et ils doivent les utiliser.

Afin d’éviter d’être pris dans le piège à ours que peut être l’intelligence basée sur les données, les chefs de produit doivent:

  • Avoir des objectifs clairs sur l’utilisation des données
  • Recueillir des données sur lesquelles ils peuvent se sentir en confiance, en utilisant les bons outils
  • agir sur lui

Choisir les bons arbres (ou données)

Un cycle d’itération d’application mobile habituel ressemble à l’image ci-dessous:

mesure-apprendre-construire-730x391.png
Crédit d’image: The Next Web

Les chefs de produit collectent d’abord des données, puis extrapolent des informations utiles à partir de celles-ci, puis agissent sur elles en créant de nouvelles fonctionnalités et améliorations. Ils rincent ensuite et répètent le processus, mais cette fois ils incluent tout ce qu’ils ont construit la dernière fois. Mais ce n’est jamais aussi simple. Évidemment, cette image est une simplification excessive du processus qui peut en fait être contre-productive.

Donc, la première chose à laquelle ils doivent faire attention est de s’assurer qu’ils ne surveillent pas les données inutiles. Il est temps de choisir les bons arbres de la forêt.

Selon la phase actuelle du projet et ses objectifs finaux, ceux-ci peuvent aller de l’analyse des plantages au nombre d’inscriptions de nouveaux comptes, aux taux de rétention, aux taux de fermeture et aux désinstallations. Par souci d’argument, disons que notre chef de produit se concentre sur les taux de désinstallation de leur application, car ils sont assez élevés.

Maintenant, des objectifs clairs doivent être fixés. La «réduction des désinstallations» comme objectif est l’un des pièges à ours – l’objectif ne doit jamais être vague et numérique. Au lieu de cela, l’objectif doit être de comprendre quel est derrière le taux inhabituellement élevé de désinstallations et se concentrer sur cela. À ce stade, une bonne utilisation des outils d’analyse qualitative est essentielle. En utilisant des outils d’analyse qualitative, comme Appsee, qui fournissent des données riches telles que des cartes thermiques tactiles et des enregistrements de session utilisateur, les chefs de produit peuvent obtenir une vue claire et complètement intacte de la façon dont leur application, y compris les dernières fonctionnalités et améliorations, est utilisée. Comme le montre l’image ci-dessous, les données qualitatives aident à rationaliser le processus d’analyse des données. Des informations peuvent être obtenues directement et ces informations peuvent ensuite stimuler une analyse qualitative des données. C’est alors que notre bûcheron allume la tronçonneuse.

flow-appsee-dark-73830.png

Regarder quelques enregistrements de session utilisateur en temps réel permet aux chefs de produit de voir le moment exact où les utilisateurs ont décidé de désinstaller une application, ce qui peut les aider à comprendre quels sont les problèmes, les UX ou les obstacles à la performance qui ont motivé les utilisateurs à abandonner complètement l’application.

Enfin, ne laissez pas ces données inactives. Les analyses qualitatives, associées à leur contrepartie quantitative, permettent aux chefs de produit d’être vraiment proactifs. Au lieu d’attendre des données agrégées pour résoudre un problème de crash ou d’utilisation, ils peuvent détecter les problèmes de produit instantanément et répéter en toute confiance. Ils peuvent considérablement améliorer les cycles de publication, gagner un nombre incalculable d’heures à deviner la signification d’une certaine mesure et valider les hypothèses et les résultats des tests avec des preuves visuelles claires.

En conclusion

L’utilisation de l’analyse d’applications pour améliorer les cycles d’itération est généralement considérée comme un «must» dans le flux de travail d’un chef de produit. Mais tout comme un bûcheron peut abattre un arbre avec une tronçonneuse sans l’allumer, il est essentiel que les chefs de produit sachent exactement quels outils utiliser, comment utiliser leurs outils et dans quel but final.

Il y a trois étapes sur ce chemin: la première consiste à choisir les bonnes données (le bon arbre), la seconde consiste à utiliser tous les outils à votre disposition, à la fois quantitatifs et qualitatifs (allumer la tronçonneuse), et enfin – pour vous assurer que les données recueilli est utilisé vers un objectif final qui a été précédemment défini. Ce n’est qu’ainsi que les chefs de produit s’assureront de ne pas perdre leur précieux temps et leurs ressources à ne rien faire et à ne rien faire.





Source

Laissez Votre Commentaire