Heetch’s Application Redesign

Une Tribe qui place au cœur de cette réflexion les interactions humaines, l’entraide et le partage qui sont des valeurs essentielles à notre métier.
Mais concrètement, qu’est-ce que c’est ? Au-delà d’une simple et classique plateforme collaborative, « Design Corner » sera un outil d’échanges et de synergies qui vous permettra d’être proactifs face à vos challenges, le tout animé par des PO, PM avec des invités de marque du monde du Product Design !

Notre objectif étant de vous aider à solutionner vos problématiques produits sur des thématiques comme celle du « Redesign de l’application de Heetch » dont l’article ci-dessous vous a été écrit par l’ancien « Head Of Product Design » de Heetch et actuel co-fondateur de « The Design Crew » Julien Pelletier.

La longue et épique aventure du redesign d'une application

C’est le rêve de tout designer : arriver dans une startup et travailler sur un projet ambitieux de redesign d’une application. C’est d’ailleurs bien souvent une envie que partage tout le monde dans la boite, surtout quand le design actuel commence à accuser le poids des années et qu’on se lève chaque matin avec l’amère impression que nous application est restée bloquée à l’ère de Windows 95.
Ce que cette courte introduction ne dit pas, c’est à quel point ce rêve peut se transformer une vraie aventure et vous embarquer sur plusieurs années. Dans cet article, Julien Pelletier, ex Head of Product Design va vous conter ce périple épique qui l’a amené avec son équipe à redesigner l’application de Heetch…

Chapitre 1 : la genèse

Heetch est une application de mobilité qui originellement permettait à chacun de prendre sa voiture et d’effectuer quelques trajets avec des passagers souhaitant se déplacer dans de grandes villes et leurs banlieues afin d’amortir le coup de leur véhicule. Un très bon plan qui surfait sur la vague de l’économie collaborative du début des années 2010. Après une décision de justice n’autorisant plus cette pratique, la société a pivoté pour proposer le même service avec des chauffeurs professionnels.
D’autant que je me souviens, le « redesign de l’app » a toujours été un sujet qui revenait inlassablement dans les discussions, et ce, dès mon arrivée chez Heetch. Personne n’était satisfait du look & feel du produit et l’identité visuelle n’avait que très peu évolué depuis la création de la boite en 2013.

Pire encore, les écrans de l’application étaient très hétérogènes (on comptait les styles de boutons ou d’icônes par dizaines) et sont devenues un morceau conséquent de l’infâmement célèbre “dette technique”, ralentissant l’implémentation de nouvelles interfaces et créant des frustrations sur ce qu’il était possible de faire.

Il fallait agir, mais pourquoi alors aura t’il fallu attendre 3 ans pour qu’une toute nouvelle version de l’app voit le jour ?
Pendant longtemps, le sujet est resté au stade « d’idée », ou « d’envie » partagée par toutes les équipes. Tout le monde en parlait, mais les choses n’avançaient pas. Ce n’était pas un “projet” à proprement parler. Rétrospectivement, cela peut probablement être imputé à 2 raisons :

1. Ce n’était le problème de personne

Personne n’avait jamais été nommé responsable de ce projet de redesign. Difficile de faire avancer un chantier sans quelqu’un d’identifié comme étant “en charge”. Ça tombait bien, je venais d’être recruté pour me concentrer sur les missions product design chez Heetch, je pouvais donc faire de ce problème MON problème.

2. Ce n’était pas inscrit à la roadmap

Aucune bande passante n’avait été allouée à ce redesign. C’est le genre de sujets qui tombent dans la catégorie “important mais pas urgent”, toujours doublés dans la roadmap par des projets aux retombées business plus immédiates.
Cependant, en discutant avec les développeurs mobiles, on se rend compte que la création d’interface de leur côté se fait souvent dans la douleur et qu’une rationalisation en composant ferait le plus grand bien.

Il fallait donc que tout le monde soit convaincu que ce redesign serait un investissement et qu’on pourrait y voir un gain de productivité tant d’un point de vue design que de développement lors de la création de futures interfaces.

Les raisons d’un redesign peuvent être diverses : cela peut être motivé par des changements importants dans l’identité de la marque, des retours utilisateurs insistants ou comme nous la perspective de voir notre vitesse d’implémentation augmenter. Dans tous les cas il faut définir un but qui soit autre que « ça nous ferait kiffer » pour qu’à tout moment, on puisse facilement répondre à la question « au fait pourquoi on s’est lancé là-dedans ? »
Une fois avoir trouvé un responsable et témoigné du gain de vélocité qu’apporterait un tel chantier nous avons pu justifier de l’intérêt de se lancer et de passer à l’étape suivante.

Chapitre 2 : la grande exploration

Tous nos collègues ne passaient pas leurs journées sur Dribbble mais voyaient à quoi ressemblaient les autres applications et comprenaient qu’un fossé se créait entre notre application et ses concurrentes en terme de look & feel. Personne n’avait pour autant jamais travaillé sur un projet de cette nature, alors par où commencer ?
La première chose que je me sentais capable de faire avec uniquement des ressources design était de montrer à quoi cela pouvait ressembler. L’équipe est donc partie à la recherche d’un look & feel qui conviendrait à la direction que les visual designers et les cofondateurs voulaient donner à l’identité visuelle de Heetch (car elle datait un peu elle aussi). Nous avons réalisé de rapides moodboards et demandé quelles étaient les apps les plus stylées que l’équipe avait pu utiliser ces derniers temps. Armés de toutes ces idées, la grande exploration a pu commencer.

Des centaines d’écrans ont été créés mais au bout d’un moment nous commencions à nous perdre et à tourner en rond. Une aide extérieure aurait été la bienvenue et c’est à ce moment que nous avons sollicité le renfort de 2 designers freelances (Fred et Fabrice) venus pour apporter un regard nouveau sur notre travail.

Nous avons réussi à accorder à peu près tout le monde sur une “intention”. Ce n’était pas des specs, ce n’était pas des écrans finalisés, mais juste une direction à suivre. Les choses étaient concrètes et l’équipe design était impatiente de travailler sur cette nouvelle app. Mais une application ne se construit pas qu’entre designers, il fallait enrôler de nouveaux alliers…

L’exploration à continué quelques jours, nous avons rebondi sur le travail des uns et des autres quand un beau jour…

Chapitre 3 : la communauté du redesign

Nous avons embarqué l’intégralité de l’équipe mobile (développeurs iOS, Android, PM) dans une superbe maison de maitre pour ce que tout le monde se souvient comme “la retreat redesign”. Pendant 3 jours, nous avons essayé de décliner notre design sur plusieurs écrans, testé plusieurs concepts et essayé d’anticiper leurs challenges techniques.

Il n’y avait pas de neige au moment de la retreat, mais on est d’accord que ça fait plus épique, non ?

Le but n’était pas d’avancer sur l’implémentation de ce design, mais de créer un groupe soudé de personnes qui ne se connaissaient pas tous très bien et qui allait pourtant devoir collaborer ensemble pendant un long moment pour mener à bien ce redesign. Plusieurs prototypes ont été créés et nous avons pu enfin entrevoir ce que nos utilisateurs allaient ressentir en ayant notre nouvelle application dans les mains. Nous sommes revenus de ces 3 jours motivés comme jamais, prêts à en découdre et encore insouciants des difficultés que nous allions rencontrer sur la route.

Chapitre 4 : l’interminable voyage

On s’était jusqu’alors bien amusés, mais c’est à ce moment que les choses sérieuses ont commencé. Il fallait préparer le terrain pour une implémentation que l’on imaginait progressive : nous allions distribuer un lot d’écrans à redesigned à chacune de nos squads et ils pourraient l’intégrer dans leurs roadmaps pour le quarter à venir. Easy. Peasy.
À noter que même si c’était tentant, nous avons gardé comme consigne de ne pas accompagner ce redesign des nouvelles features que nous avions prototypé lors de la retreat. Garder un scope n’incluant que le travail de création d’interfaces nous assurait de ne pas ralentir l’implémentation pour des considérations fonctionnelles liées à ces nouvelles features. Chaque chose en son temps en quelques sortes. De toutes façons avec ce nouveau design system, il aurait été facile de par la suite s’attaquer à ces nouvelles idées.

Nous avons eu l’impression qu’il fallait à la fois construire nos design system en parallèle des écrans de l’app :

- Cela permettait de s’assurer que l’on rationalisait au maximum nos composants en traitant tous les use-cases possibles de notre application
- Mais aussi de ne pas créer des composants inutilisables parce qu’ils avaient été créés à part et hors contexte.
Plus de 200 mockups ont donc été construits à cette étape : chaque écran de l’app dans une quantité astronomique de variations différentes : loading state, empty state, error state, spécificités liées aux pays, au moyen de paiement…

Accompagnés par des dizaines de composants constituants Flamingo, notre tout nouveau design système créé pour l’occasion.

Ainsi que des dizaines de pages de specs dans Notion décrivant le comportant de chaque composant et de chaque pattern.

Tout ce travail a essentiellement été réalisé « dans notre coin » avec Noémie Catel sur plusieurs mois et en utilisant le peu de temps libre que nous laissait les autres projets que comportait la roadmap. C’est peut-être cet effet tunnel qui a pesé lourd sur la perte de momentum que l’on avait réussi à créer.

Chapitre 5 : les abysses

Les mois ont passé, entre temps, nous avons aussi pris la décision de passer de Sketch à Figma. Si le changement nous a demandé de refaire tous les écrans et tous les composants dans un nouveau logiciel de création d’interfaces, il aura aussi énormément facilité la création de specs grâce à ses intégrations avec Notion et sa fonctionnalité de commentaire. C’est un changement qui peut faire peur, mais en à peine une semaine nous avions réussi à tout transférer dans Figma.
Nous avions donc un bon paquet de specs et l’espoir que nous pourrons bientôt nous intercaler entre 2 projets de roadmap pour commencer à implémenter ces nouveaux écrans. Ça… C’était la théorie : en réalité une startup est beaucoup moins prévisible que ça et de nouvelles urgences ne cessaient de venir s’intercaler dans notre roadmap avec pour conséquence de venir avec son lot de nouveaux écrans de d’ajustements à faire sur les écrans redesignés.

J’adore quand un plan se déroule sans accr… Oh wait…

Ces nouveaux projets importants et urgents s’accompagnaient évidemment de nouveaux écrans à rafraîchir et il était devenu si difficile de maintenir nos versions redesignées à jour qu’un fossé se creusait entre l’application en production et nos specs, entrainant davantage l’éloignement du projet dans la roadmap.

Chapitre 6 : “Blitzkrieg”

Il était impensable de voir notre projet et tous les efforts fournis tomber dans l’oubli et se résilier à conserver ces interfaces si difficiles à maintenir et faire évoluer. Il fallait agir vite et agir fort ! Après un dernier run pour avoir le flow principal de l’app (commander un trajet) à jour dans nos specs, nous nous sommes lancés dans une batterie de tests d’utilisabilité pour s’assurer une dernière fois que nous n’allions pas implémenter des écrans que nos utilisateurs n’arriveraient pas à comprendre.
Enfin, nous avons réuni l’ensemble des développeurs mobile de l’entreprise pour leur demander de se joindre à nous dans cet ultime effort : un « redesign raid » de 2 semaines durant lequel nous avions pour objectif d’implémenter ce flow de commande. Il a fallu mettre de côté l’idée de tout implémenter en même temps pour se concentrer sur les écrans essentiels pour les passagers et garder tout le reste (profil, signup, coté drivers, …) pour plus tard.

3 designers étaient de la partie et se relayaient pour être « on call » et être capables de répondre aux développeurs en quelques minutes si une partie des specs n’était pas claire ou si un écran avait été oublié.

Nous avions découpé ce flow et attribué chaque partie à un ou plusieurs développeurs. Au total une dizaine de développeurs ont travaillé d’arrache-pied pour livrer une version qui nécessitait certes d’être un peu débuggé et peaufiné, mais néanmoins une version fonctionnelle !

Chapitre 7 : un futur radieux

Il restait donc quelques bugs qu’il a fallu corrigé et redispatcher entre les développeurs qui avaient eux retrouvé leurs équipes respectives. On s’attendait à ce qu’ils reste quelques ajustements en sortie de raid. L’objectif c’était qu’il ne faudrait pas y passer encore plusieurs mois pour que cette tant attendue nouvelle version de l’app puisse voir le jour.
Au bout de quelques semaines l’app était prête à être déployée et c’est grave à Marie Bihl une de nos product managers que toute la partie delivery (tracking plan, release, monitoring) a pu se dérouler sans trop d’embuches. En A/B testant notre nouveau design face à l’ancien nous avons pu déterminer que le taux de conversion sur le flow de commande avait augmenté de quelques pourcents.

Autres éléments de satisfaction : plusieurs messages de développeurs louant la facilité d’implémenter des nouvelles interfaces arrivaient à nos oreilles (qui en réalité était le channel Slack lié au design system). Les bénéfices de ce redesign se sont également vus dans l’équipe design qui disposait désormais d’un language et de plusieurs outils communs pour la réalisation de leurs interfaces.

Quelques mois plus tard, l’équipe brand s’est musclée pour accueillir de nouvelles personnes (creative director, head of brand, head of marketing…) et d’importants efforts ont été déployés pour donner à la marque Heetch une toute nouvelle identité. Nouvelles couleurs, nouveau logo mais surtout nouvelle personnalité. Notre design system en a donc été impacté et quelques modifications ont du être apportées. L’avantage d’avoir adopté une approche systématique pour nos interfaces s’est fait ressentir lorsque nous avons fait évoluer Flamingo : en une poignée de journées seulement les nouveaux composants ont été créés, les specs rédigées et les changements implémentés.

Chapitre 8: Épilogue

Le chemin a été long et tortueux. Je ne suis pas sûr avec le recul que j’aborderais les choses de la même façon si tout était à refaire. Quelques enseignements glanés en cours de route :
Le redesign de notre application était resté au stade « d’envie » jusqu’à ce qu’on arrive à matérialiser concrètement à quoi cela pourrait ressemble. Créer des écrans nous a permis de lancer des discussions et de tous s’aligner sur les délimitations du projet (efforts, scope, …).
Redesigner tout d’un coup nous semble quelque chose d’utopique avec le recul et choisir de ne faire que le flow principal pour ensuite s’attaquer aux autres écrans nous parait être aujourd’hui le bon choix.
C’est un projet qui va au delà de l’équipe design et créer une bonne dynamique entre les équipes product, dev et design est important pour qu’on ait tous les mêmes attentes les uns envers les autres et pour que tout le monde se sente excité par ce redesign.
J’ai quitté Heetch il y a quelques mois en initiant un projet de « design vision » qui suit désormais son cours avec l’équipe design actuelle. J’ose espérer que le travail que nous avons réalisé pendant de longs mois leur facilite également un peu la tâche pour réfléchir au futur du design de Heetch.

‍