expert-solutions-optimisation-conversion-18

Guide du sCROm, la mêlée agile de l’optimisation du taux de conversion

Le sCROm – cycle continu de l’optimisation de la conversion lean et agile.

Prenez en main l’optimisation de vos taux de conversion, entrez dans la mêlée sCROm !

Plutôt qu’une approche non structurée qui se traduit souvent par des tests isolés qui ne mènent pas très loin. L’expérience démontre que la clé du succès est dans l’adoption d’une approche structurée et quotidienne de l’optimisation Web. J’ai imaginé le sCROm pour aider les entreprises à organiser leur processus d’optimisation Web et tirer parti des enseignements issus des observations et des expérimentations. Le sCROm est un cocktail Lean et Agile, mixant le Scrum, le Kanban et le Lean Analytics/UX pour optimiser un processus de conversion. Un  véritable laboratoire de recherche et d’innovation qui  maximise les résultats,  la connaissance, le contrôle et la satisfaction.

sCROm-processus-optimisation-conversion-webAnalyste-franck-scandolera
sCROm-processus-optimisation-conversion

Le sCROm répond aux problématiques d’optimisation Web de toute entreprise, Start-up, PME ou Grande Entreprise. Le processus est taillé sur mesure pour s’adapter à l’environnement de l’entreprise. L’approche est empirique, dans le sens où l’adaptation se fait par l’expérimentation – « Quelle est la limite de ceci ? Testons et décidons »…

Le Framework du sCROm

Le sCROm pourrait se résumer en une recherche itérative agile en vue d’améliorer la performance d’un KPI. Le pilotage du processus est basé sur le Kanban, qui offre le triple avantage :

  • D’être simple pour être dimensionné rapidement pour une ou plusieurs personnes, grâce à la limite de TAF (Travail À Faire) par étape.
  • D’être souple pour répondre à de nouveau besoin, grâce à la modification libre d’une tache « à faire » par une autre plus urgente.
  • D’être accessible, grâce à la visualisation du workflow dans un tableau unique.

Le cycle de recherche est organisé autour des 4 grandes activités Lean Analytics  :

  • la mesure pour déterminer ce qui pourrait être améliorer
  • l’hypothèse pour identifier les possibilités d’amélioration
  • le test pour valider ou invalider les hypothèses
  • la décision pour statuer sur la suite de la recherche.

Les rôles.

  • Le sCROwner, c’est le responsable CRO du produit, à ce titre, il est en charge de la Mesure et de la Décision et intervient à l’étape de l’Hypothèse. C’est lui qui priorise la recherche.
  • le sCROm master (1 personne) et/ou la sCROm team (une équipe), est en charge des Hypothèses et des Tests et intervient également au moment de la Décision. Selon l’environnement de l’entreprise, la responsabilité de ces étapes peut être assumée par une ou plusieurs personnes. Les compétences sont pluridisciplinaires (Web analytics, UX designer, Marketing digital…) et autogérées (il n’y a pas de chef de projet, mais en cas d’équipe, si nécessaire une personne peut endosser le rôle de sCROm master pour faciliter l’organisation du flux).
  • Les Observateurs sont les personnes qui souhaitent avoir une vue sur le projet sans réellement s’investir dedans. Il peut s’agir par exemple d’experts techniques ou exécutifs.

les activités

La mesure
Tour de contrôle de la performance et de l’expérience utilisateur. Le sCROwner est à l’avant poste de l’optimisation, il diagnostique les problèmes de performance et mesure l’efficacité des recherches.

Objectif :

  • Mesurer la performance des KPI stratégiques
  • Mesurer la performance des KPI opérationnels CRO
  • Mesurer l’évolution de l’expérience utilisateur à travers des métriques AIDAS (Attention, Intérêt, Désir, Action, Satisfaction) et RFD (Récence, Fréquence, Durée)

Qui : le sCROwner

Le diagnostic
Aiguillage de l’optimisation – D’après ses observations, le sCROwner diagnostique et hiérarchise les freins à la conversion .

Objectif :

  • Qualifier les problèmes de performance sous la forme d’une fiche de diagnostic
  • Prioriser les diagnostics dans un backlog « Diagnostic ».

Qui : le sCROwner

Les hypothèses
Atelier d’idéation collectif pour identifier la meilleure réponse à apporter au problème constaté par le diagnostic. Cycle de brainstorming et si nécessaire de design thinking pour transformer le diagnostic en hypothèse, puis en MVP (Minium Viable Product), puis en Plan de test.

Objectif :

  • Génération d’idée individuelle pour traduire un diagnostic en hypothèses
  • Design collaboratif pour donner corps à l’hypothèse, le MVP qui sera testé.
  • Détailler l’hypothèse et le MVP dans un plan de test
  • Prioriser les plans de test dans un backlog « Plans de test ».

Qui :  le sCROwner,  la sCROm Team, le sCROm Master, toute autre personne concernée par le sujet.

La planification
La planification a pour but de choisir les prochains Plans de test qui seront exécutés et de les décomposer en action, en tache. La sélection est faite sur la base de l’importance donnée au Plan de test par le sCROwner, sur certains facteurs externes pouvant biaiser le test (plan média, effet de saisonnalité, modification fonctionnelle ou technologique du site…) et également sur la capacité de production de l’équipe de test. Selon le principe du Kanban, le nombre de taches à faire (TAF) de chaque étape du cycle est limité pour éviter l’engorgement du flux.

Objectifs :

  • Sélectionner les n prochains Plans de test qui seront exécutés selon la limite du TAF de l’étape « Prochains » du tableau Kanban de Tests. (1 espace libre = 1 nouveau Plan de test avec ses fiches Actions)
  • Identifier pour chaque Plan, sous forme de fiche Action, tous les éléments à produire (design, intégration, QA) pour pouvoir lancer le test dans les meilleures conditions.
  • Prioriser les plans de test dans le backlog du tableau Kanban de « Tests ».

Qui :  le sCROwner,  la sCROm Team, le sCROm Master.

La production

tableau-kanban-scrom-optimisation-conversion-webAnalyste-franck-scandolera
tableau-kanban-scrom-optimisation-conversion


La production des tests est organisée sur le modèle Kanban, c’est-à-dire que le suivi du processus est visuel, accessible par tous et que chaque étape du flux est contrainte par une limite de TAF. Une limite qui force la sCROm Team ou le sCROm Master à terminer ce qui est commencé, afin d’éviter l’accumulation de taches commencées et non terminées.  Une fois une action terminée « Done », une nouvelle peut être initiée, si la limite de TAF de l’étape le permet. Par exemple, dès qu’un test est considéré comme terminé, il libère un conteneur « Test en cours » pour initier la production d’un nouveau test. On glisse donc dans  la première colonne « En cours », un Plan de test avec toutes les fiches actions qui ont été définies au moment de la planification. Si le TAF des étapes Design le permet, la personne en charge de cette phase sélectionne une fiche action à produire. Une fois terminée, la fiche est déposée dans la partie « Done ». Si la tâche n’est pas terminée pour x raisons, et si l’état du TAF le permet, une nouvelle action peut être lancée. Par contre , si l’état du TAF ne le permet pas, la personne doit faire en sorte que les taches de l’étape suivante soient finalisées pour libérer au moins un conteneur de production, etc.

Un point quotidien permet de passer en revue le tableau Kanban et mesurer la production et l’attribution du TAF. Il permet également d’identifier les blocages, de comprendre les causes et de trouver collectivement la meilleure solution pour fluidifier le processus.

Objectifs :

  • Design : donnez corps aux MVP du Plan de test en désignant tous les composants graphiques qui seront testés, telles que les variations d’un bouton,  la version B d’une page.
  • Intégration : configurer l’outil de test, le site web et tout outil intervenant dans le test, comme un sondage.
  • QA : Valider la qualité du test (intégration, paramètre test, données)

Qui :  la sCROm Team, le sCROm Master.

Le test
Activation et conduite du test.
Une fois que votre test est près, la qualité d’implémentation validée et que la limite de TAF le permet, le test peut-être activé. Durant cette période, c’est surtout l’outil de test qui travaille, toutefois, les données doivent être surveillée de près la qualité des données collectées afin de minimiser (à défaut de supprimer) l’introduction de biais durant l’exécution.

Lors du point quotidien, il est également recommandé de passer en revue les données des tests en cours.

Objectifs :
– Informer les parties prenantes du lancement du test.
– Surveiller la cohérence des données réceptionnées
– Surveiller de près la performance afin de stopper rapidement les variations visiblement contre-performantes.

Décider
Une fois un test terminé et le résultat validé, un bilan est fait avec le sCROwner pour  décider de la suite à donner. Il y a 3 possibilités :

  • Le résultat est positif, le bilan du test peut être communiqué et déployé sur le site.
  • Le résultat est mitigé, l’hypothèse et/ou le MVP peuvent être légèrement modifiés.
  • Le résultat est négatif, il faut revoir complément l’hypothèse de départ.

Communiquer
Il me semble important de ritualiser la communication des résultats de test à l’ensemble de l’entreprise, car en plus du rôle pédagogique et d’évangélisation, c’est l’occasion de valoriser et stimuler les acteurs de l’optimisation.

Le sCROm , globalement c’est un jeu de pronostique, pourquoi ne pas en profiter pour animer l’optimisation en impliquant tous les collaborateurs de l’entreprise à travers l’organisation de concours de « meilleure hypothèse » ou de paris sur les résultats des prochains tests… Alors, en fin de présentation, ouvrez les paris sur le prochain test.

Retour en haut