User flow, User Journey, Quelle est la différence ? Ça sonne pareil, mais ce n'est pas pareil.

User stories & User flows, deux concepts similaires mais bien différents. Leurs objectifs commun: faciliter la conception, la compréhension et la planification d’un produit ou service.

Démêlons ensemble ce sac de nœud, chacun a son rôle à jouer.

User Journey

L’User Journey, aussi appelée customer journey est une série d’étapes détaillant les différentes actions qu’un utilisateur doit effectuer pour utiliser notre produit ou une partie de notre produit. Elle se base sur les personas des utilisateurs types.

L’User Journey prend en compte les éléments environnementaux extérieurs et contextuels à notre produit, par exemple le lieu, l’heure ou une condition d’utilisation comme du temps à tuer dans les transports publics.

Formellement ces recherches se traduiront par une User journey map, une carte chronologique des actions de l’utilisateurs intra et extra produit afin de découvrir les points bloquants du parcours de l’utilisateur.

On cherchera à définir entre autre pour chaque étape de l’utilisateur son état émotionnel, ses aspirations, ses besoins pour découvrir les points de frictions et nos potentielles opportunités.

Les points importants à développer seront:

  • Les actions de l’utilisateur.
  • Ce que pense l’utilisateur.
  • L’état émotionnel de l’utilisateur. Les points de frustrations sont les points les plus intéressants car ils sont sources d’améliorations et d’opportunités.

Grâce au mapping nous avons maintenant une bonne idée des motivations et actions de notre utilisateur cible. Il est temps de rentrer dans les détails de notre produit, it’s User Flow time baby !

User flow

L’user journey et son mapping nous ont permis de définir (ou redéfinir) le chemin de l’utilisateur ainsi que ses besoins et ses désirs. L’User Flow va se charger de découper chaque grande étape en petites actions nécessaires à l’utilisateur pour achever l’étape de la journey.

L’user flow se concentre uniquement sur les actions utilisateurs à l’intérieur de notre produit et se traduit sous la forme d’un flow chart, une carte des chemins empruntables par l’utilisateur dans notre produit pour accomplir son objectif.

Cette méthode aidera grandement à définir quelles informations et actions seront nécessaires sur chaque écran pour que l’utilisateur avance sans friction.

Une fois défini, un user flow est tout naturellement un très bon outil pour nous aider à définir et planifier les features ou modules à développer afin d’obtenir un produit intuitif et agréable à utiliser.

Ce qu’il faut garder en tête:

  • L’objectif du flow. Il faut se focaliser sur une action précise de l’utilisateur afin de rester clair et précis.
  • Le contexte. Comment l’utilisateur entre dans l’application (email, publicité, etc.), l’action principal qu’il veut effectuer, il peut être défini par une User Story map et les personas.
  • Les informations et points d’action. On définira ce que l’utilisateur peut trouver sur chaque écran pour avoir une vision claire des possibilités de notre produit.

En Résumé, l’User Journey et l’User Flow ont des fonctions distinctes mais sont tous les deux des outils très utiles pour comprendre notre utilisateur et notre produit.
Ce sont également d’excellents véhicules pour communiquer et fédérer autour de vos idées en interne comme en externe.

Bonne journey ! 

 

Qu’est ce que le développement Agile et la méthode Scrum ? On se concerte, on s'adapte et on développe !

La très fameuse méthode Agile permet de diviser et répartir efficacement les tâches à accomplir lors du développement d’un important projet.

Elle permet également comme son nom l’indique de rester agile, c’est à dire d’adapter la charge de travails et les priorités aux contraintes techniques et délais de livraison.

C’est un procédé très utile dans le développement web et d’applications car contrairement à un projet physique comme la création d’un immeuble par exemple, il est très facile, une fois le produit livré d’ajouter des briques ou d’en enlever d’autre moins fonctionnelles.

En bref le produit numérique est malléable dans le temps, la méthode agile permet de d’exploiter pleinement cette malléabilité.

Oui mais Jamie, c’est bien beau tout ça, mais comment ça marche concrètement ?

Avant de commencer l’explication, commençons par définir les différents parties prenantes aussi appelé stakeholders.

Le Product Owner, C’est la personne en charge de la définition du produit final et de ses fonctionnalités. C’est lui qui choisi, en accord avec le client, les dates de livraison et les contenus livrés. Il lui incombe la charge de définir les tâches et leurs priorités. En fin de sprint, il valide le travail effectué.
Il a la responsabilité du retour sur investissement, c’est lui qui représente les intérêts du client.

Le Scrum Master, il est en charge du management du projet, de son bon déroulé et s’assure de l’application des pratiques et valeurs du Scrum. Pour ce faire il doit s’assurer que les équipes sont fonctionnelles à 100% et qu’elles disposent de tout ce dont elles ont besoin pour travailler.
En cas de problème, il doit éliminer les points bloquants et dégager la route aux équipes pour qu’ils puissent continuer leur sprint. Il agit comme facilitateur au sein de son équipe.

L’équipe / Les équipes, englobent toute autre partie prenante qui sera coordonnée afin de développer le produit, cela peut inclure des développeurs  mais également des designers, des data analysts, etc. selon les besoin du projet.
Chaque membre de l’équipe est au même niveau hiérarchique.

C’est bon ? La team est en place, allez hop ! On passe à la méthode !

Le développement agile découpe la création d’un produit en plusieurs sprint.

Un sprint est défini par deux choses:
Sa durée dans le temps, elle peut être définie entre 1 et 4 semaines mais doit être consistante, si on choisi 2 semaines, on doit s’y tenir jusqu’à la fin du développement.
Son objectif, chaque sprint doit aboutir à un délivrable, la mise en place d’une news letter, la création d’un module de réservation, en bref, quelque chose de concret qui peut être soumis au feedback du client.

Chaque sprint est divisé en tâches à compléter par les stakeholders.

Le Product Backlog

Le produit déjà divisé en user stories est découpé par le product owner en une liste de tâches à effectuer, un chat nécessite entre autre une manière de s’inscrire en tant qu’utilisateur, la mise en place backend, un design.

Chaque uses stories est constitué d’une une multitude de tâches:

Une fois les tâches définies, le product owner prioritise les tâches. L’ordre de priorité et la liste de tâches peut et va évoluer tout au long du développement.

Le Sprint Backlog

À partir du product backlog, l’équipe va choisir les tâches qu’elle choisit d’accomplir durant un sprint.  L’équipe peut suivre la prioritisation du product owner mais également choisir d’autres tâches moins importantes, il y a plusieurs raison à cela.
– Le sprint backlog doit suivre une logique de délivrabilité pour pouvoir périodiquement solliciter les feedbacks du client et rectifier le tir au prochain sprint si besoin.
Par exemple la mise en place d’une newsletter nécessite la création d’une base de donné (high prio), d’un bouton de souscription sur le site (high prio) et de l’adaptation de la charte graphique à la news letter (low prio).
– Les membres de l’équipe peuvent se concentrer sur une grosse tâche longue et remplir la fin de leur agenda avec de plus petits items.
– Certaine tâches sont dépendantes du développement d’autre tâches du backlog.

Le Sprint

Durant le sprint, chaque développeur travaille sur les tâches qu’il a choisit d’accomplir.

Chaque journée du sprint commence par un scrum (une mêlée), c’est une réunion rapide, on ne s’assoit pas, on reste debout et chacun discute avec l’équipe en 5-10 min de 3 choses:
– Qu’a-t-on fait la veille ?
– Quels furent les problèmes rencontrés ?
– Que va-t-on faire aujourd’hui ?

Ainsi toute l’équipe sait où elle en est au jour le jour et sait si elle respecte ses objectifs.

La fin d’un sprint doit se solder par la livraison d’un produit, d’une feature ou  d’une partie du produit que le product owner peut montrer au client afin de recevoir ses feedbacks pour la suite du développement et pour rester transparent.

 

La Sprint Review

Enfin la fin d’un sprint se conclut par une réunion faisant le point sur le déroulement du sprint, ce qui a bien marché et ce qui a moins bien marché.
Le but n’est pas de juger mais de rester dans un esprit d’amélioration de l’équipe au globale mais également au niveau individuel afin d’être plus efficace au prochain sprint.

Pour poursuivre votre quête d’agilité je vous invite à quitter un instant la technique pour rejoindre le philosophique en lisant cet article du blog qualitystreet.fr qui énumère les valeurs derrière le développement agile car je suis convaincu qu’on fait toujours mieux les choses quand on sait pour quoi on les fait.

Bon sprint !