Se lancer dans un projet de redesign de son application mobile est une tâche aussi challengeante que trouver une aiguille dans une botte de foin, sauf que la botte de foin est en réalité un labyrinthe de défis techniques, de besoins utilisateur changeants, et qu'en plus elle est en feu.
Plus sérieusement, entreprendre le redesign d'une application mobile est un projet très excitant ! C'est l'opportunité parfaite d'améliorer l'expérience utilisateur et de remplacer les anciennes techno obsolètes par de nouvelles plus modernes et plus performantes. Cependant, c'est aussi un défi de taille plutôt difficile qui comporte de nombreux défis…
Chez Gojob, nous avons récemment décidé de remplacer notre ancienne app par une nouvelle et de lui faire peau neuve. En tant que PM, c'était la première fois que je me lançais dans un projet d'une telle envergure, et je ne vais pas vous mentir, j'aurais aimé avoir mieux anticipé certains challenges que cela allait impliquer avant de l'entreprendre. Mais, ça n'aurait pas été drôle et puis je n'aurais pas pû vous rédiger cet article magnifique si ça avait été le cas ! En effet, au-delà de la nécessité d'avoir une équipe on 🔥 et prête à tout pour créer LA meilleure app de la terre, il faut également pouvoir anticiper les coûts, les délais et les éventuels imprévus qui pourraient survenir pendant le développement d'une telle application mobile. Il est également important de s'assurer que l'application sera compatible avec différents appareils et systèmes d'exploitation, ainsi que de planifier une stratégie de marketing et de promotion efficace pour s'assurer que l'application atteigne son public cible, toussi toussa quoi…
Bien sûr, je vous dis ça maintenant comme si cela coulait de source, mais il y a plein d'éléments mentionnés ci-dessus que j'ai complètement oubliés ou auxquels je n'ai pas assez prêté attention pendant le processus d'où l'idée d'écrire un article sur le sujet !
Avant de commencer, un peu de contexte :
Il y a plusieurs raisons pour lesquelles nous avons décidé de refaire une beauté à notre application mobile chez Gojob.
- Notre technologie de base (Cordova, une "create-react-app" full client side) était devenue obsolète et difficile à maintenir. Cela rendait délicat l'ajout de nouvelles fonctionnalités et la correction de bugs. Par exemple, à chaque fois que nous devions réparer quelque chose ou ajouter un nouvel élément sur l'app, nous devions faire un nouveau build/package/release ce qui était très chronophage. Il était donc temps pour nous de repenser notre architecture technique afin de faciliter les mises à jour et d'assurer une meilleure stabilité à long terme.
- Nous voulions également que notre application ait un design plus moderne et attrayant pour les utilisateurs. Le design étant un élément crucial de l'expérience utilisateur, il peut avoir un impact significatif sur la manière dont les Gojobbers (les intérimaires embauchés par Gojob) interagissent avec notre application. En modernisant notre design, nous espérions la rendre plus en phase avec les tendances actuelles pour ensuite retenir les utilisateurs et augmenter l'engagement et l'utilisation de la-dite application.
- Refaire notre application mobile était une opportunité pour nous d'améliorer l'expérience utilisateur en général et d'ajouter de nouvelles fonctionnalités. Nous avons pris le temps de comprendre les problèmes principaux que nos utilisateurs rencontraient avec l'ancienne app afin de créer une expérience utilisateur plus fluide et intuitive sur la nouvelle.
Exemples de visuels de notre ancienne application :
(Photos de la nouvelle plus bas dans l'article - pas de spoilers 😉)
En somme, la décision de refaire notre application mobile a été motivée par notre volonté de moderniser notre technologie, d'améliorer notre design et de proposer une expérience utilisateur améliorée. Nous étions ravis de prendre ce projet en main, mais pas très longtemps après l'avoir attaqué, nous avons été surpris par une crise existentielle pendant laquelle nous nous sommes demandés : w̶h̶a̶t̶ ̶t̶h̶e̶ ̶h̶e̶e̶e̶e̶e̶e̶e̶ ? Dans quoi nous sommes-nous embarqués ?
Voici donc, grosse maille, une liste des défis auxquels nous avons été confrontés et comment nous y avons fait face.
1. La discovery : comment pallier un manque de connaissances historiques
Notre premier défi a été de répertorier les fonctionnalités de l'ancienne application puis de les comprendre pour savoir comment elles étaient utilisées afin de ne pas dégrader l'expérience utilisateur lors de la transition. Vous pourriez penser que c'est assez trivial car l'ancienne application avait été construite par Gojob pour Gojob, mais même si c'était effectivement le cas, l'appli avait été pensée et codée il y a quelques années par des personnes qui n'étaient plus là... Étant donné que personne de notre squad n'avait l'historique des décisions/du code de l'ancienne app, et que notre scope se limitait jusque là à une seule partie de l'application (càd : aux Acomptes, aux Contrats de travail, et au compte Épargne Temps (CET)), nous avons dû creuser dans les profondeurs du passé architectural afin d'avoir une vue plus globale. Ainsi, avec l'aide de notre super UX designer Yajing, nous avons effectué un travail de fond énorme pour élargir notre connaissance du produit et maîtriser chaque fonctionnalité existante sur le bout des doigts. Cela ne nous a pas empêché d'avoir quelques ratés, mais grâce à notre service de support et au fait que nous avions alloué du temps pour gérer les éventuels problèmes post-release, nous avons pû agir rapidement et réparer les choses.
2. La planification des tâches : l'importance des itérations
Une fois que les besoins des utilisateurs ont été bien compris, synthétisés, et découpés, il nous a été important de planifier le développement des fonctionnalités de manière efficace et efficiente. Cela a impliqué de définir les priorités fonctionnelles, d'établir un calendrier réaliste pour le développement, de hiérarchiser les tâches de développement, et de veiller à ce que toutes les fonctionnalités soient développées sans rien oublier (étape qui fût la plus difficile). Afin de pallier ce problème et éviter un gros FLOP de notre app, nous avons opté pour une mise en production à itération : nous avons d'abord lancé les fonctionnalités phares, puis mis en prod le reste petit à petit. Cependant, nous n'avons communiqué sur la disponibilité de l'app qu'une fois que nous étions prêts et qu'elle était complètement opérationnelle. Nous avons commencé, pendant 1 mois ou 2, par un double run : les deux app étaient disponibles et utilisables en parallèle : nous avons permis aux utilisateurs actifs de l'ancienne app d'aller jeter un coup d'œil à la nouvelle et de nous faire leurs retours. Une fois les retours principaux traités et les améliorations faites, nous avons fait la bascule : nous avons commencé par rediriger les URLs de l'ancienne application vers la nouvelle, nous permettant de contrôler le trafic d'utilisateurs, puis nous avons finalisé la release en écrasant notre ancienne app par la nouvelle dans les stores (Google Play, Appstore).
3. La QA : être sûrs que tout fonctionne avant de se lancer
Quoi de pire que de lancer une app qui ne fonctionne pas ou à moitié, de s'en rendre compte trop tard, et de perdre toute crédibilité auprès de la masse utilisatrice ? Afin d'éviter ce type de problème, nous avons mis en place un plan de "test" (également appelé QA (quality assurance)) en béton. Nous avons effectué plusieurs tests utilisateurs via Maze, notre outil de prototyping afin de valider des modifications d'expérience auprès de nos Gojobbers directement. Ne pouvant pas forcément mobiliser l'aide de nos utilisateurs d'un coup et trop souvent vu l'ampleur de la tâche, nous avons également fait appel à l'aide de tous les salariés de Gojob : nous avons organisé un événement de test pendant lequel tout le monde a mis la main à la pâte et a utilisé l'application en suivant multiples scénarios afin de déceler tout problème en amont. Après avoir traité tous les retours, et une fois la mise en prod itérative débutée, nous avons permis aux utilisateurs de l'app de nous faire des retours pendant 2 mois jusqu'au roll-out complet que nous avons surveillé de près chaque semaine.
Côté Tech, nous avons effectué des tests de compatibilité pour s'assurer que l'application fonctionnait correctement sur différents appareils et systèmes d'exploitation. Nous avons aussi dû faire des choix et ne pas en supporter certains : désolée les petits iPhones 6…
4. La collaboration cross-team : trop de communication vaut mieux que pas assez
Un projet de redesign d'application mobile a de nombreuses implications et répercussions sur d'autres équipes, telles que le marketing (ex: les communications CRM, la stratégie SEO…) ou la data (pour la collecte de données, le branchement Google Analytics, etc). Il est donc important de communiquer clairement et fréquemment avec ces autres équipes pour s'assurer que tous les aspects du projet sont pris en compte et pour éviter surprises de dernière minute "Ah tiens, on avait pas pensé à ça". Cet aspect là a été le plus difficile pour nous. Malheureusement, "you don't know what you don't know" et il a été dur de faire s'aligner les différentes équipes : nous avions organisé des meetings hebdomadaires pour discuter de l'avancée du projet global mais cela n'a pas suffit et nous avons, peut-être, cassé un flow d'envoi d'email marketing pour les candidatures incomplètes lors de la mise en prod de l'application. Mais je dis bien peut-être…
Comment aurions-nous pu faire pour améliorer cet aspect et éviter les ratés ? Peut-être que nommer des "owners" dans chaque équipe aurait été bénéfique, on testera la prochaine fois car on aurait pu faire mieux je crois.
Et surtout ne suivez pas le conseil ci-dessous :
5. L'attention au détail : les petites choses qui passent ou qui cassent
En plus de tout le travail de fond, il faut penser à toutes les petites choses qui ne sont pas si importantes mais importantes quand même. Voici une liste non exhaustive de sujets que j'aurais aimé prendre en compte plus tôt dans le processus de développement de l'app :
- L'impact du redesign sur le flow d'envoi d'email automatique : changer une fonctionnalité même de façon très subtile peut modifier le comportement d'envoi des emails attendus si on envoie pas/plus la bonne variable au CRM par exemple…
- Les articles FAQ sont à mettre à jour le jour du lancement de l'app pour que les utilisateurs ne soient pas pris de court dès qu'ils commencent à utiliser la nouvelle app.
- Il faut repenser (puis implémenter de zéro) touuuut le plan de tracking, surtout avec le passage de Universal Analytics à GA4.
6. L'adoption post-release : l'élément décisif
L'ancienne appli Gojob était sur le marché depuis plusieurs années : de nombreuses personnes étaient habituées à son design et à son utilisation. Comment convaincre lesdits utilisateurs de passer à la nouvelle version en sachant que la plupart des humains sont réfractaires au changement ? Pour surmonter ce défi ultime, nous avons activement communiqué sur les avantages de la nouvelle version et démontré par A+B comment elle améliore l'expérience utilisateur. Nous avons :
- Mis en place des tutoriels dans l'app pour guider nos utilisateurs ;;
- Modifié nos FAQs en amont pour éviter les incompréhensions ;
- Formé nos équipes internes à l'utilisation pour qu'elles puissent assister les Gojobbers directement ;
- Organisé des démonstrations en direct auprès de nos utilisateurs lors de déplacement sur site ;
Bien sûr, ce serait un mensonge de dire que tout le monde a été ravi du changement mais nous avons réussi à obtenir une note de satisfaction de 4,11 étoiles sur 5 (sur une base de plus de 2000 notes).
Le résultat final, une app épurée et facile d'utilisation avec un design plus moderne adapté aux besoins d'aujourd'hui :
En gros :
Le redesign d'une application mobile peut sembler intimidant (et ça l'est, no joke), mais c'est une vraie opportunité pour rester dans le jeu : maintenir une technologie de pointe, améliorer l'expérience utilisateur, ajouter de nouvelles fonctionnalités, etc... Chez Gojob, nous avons dû relever de nombreux défis lors du redesign de notre application mais nous ne sommes pas peu fiers du résultat !