Une semaine pour reconstruire notre messagerie grâce au Design Sprint ✉️ 🔨
Cela fait maintenant 9 mois que nous avons entrepris de reconstruire étape par étape les applications GuestToGuest. Après la navigation, la recherche et le calendrier, nous avons entrepris de refondre la pierre angulaire de nos applications : la messagerie.
Avec l’explosion des applications de chat (Messenger, WhatsApp, etc.), il devenait urgent d’adapter notre messagerie aux nouveaux usages et habitudes des utilisateurs, tout en simplifiant leur expérience.
Ce changement était d’autant plus important que nous venions de changer cette même messagerie sur notre version desktop. Mais voilà, nous avions des réticences en interne pour modifier nos applications, car nous venions justement de changer la messagerie sur notre version desktop. Concrètement, la refonte de notre messagerie desktop nous a pris 9 mois au lieu des 3 prévus à l’origine. Le temps et l’énergie dépensés dans le projet avaient laissé des séquelles et personne ne voulait réitérer la même expérience sur mobile.
Il nous fallait donc un moyen de prouver que nous pouvions changer rapidement la messagerie sur mobile et que nous étions sûrs que ces changements seraient bien accueillis et bénéfiques pour nos membres. Nous nous sommes donc tournés vers le Design Sprint de Google Venture, une méthodologie permettant de créer, tester et valider un prototype en 5 jours. Cependant, du fait de contraintes internes, nous avons dû adapter le Design Sprint à notre façon. Voici comment nous avons procédé :
0. Constituter une équipe de choc 💪
Pour travailler sur la refonte de la messagerie de nos applications, nous avons décidé de constituer une équipe restreinte composée de trois personnes : Alexandre, Clément et moi-même.
Alexandre Humeau, Product Owner
Alexandre était en charge de la refonte de la messagerie desktop. Il savait donc quelles étaient les attentes de nos membres, les nouvelles fonctionnalités implémentées dans la nouvelle messagerie, le fonctionnement de cette dernière, mais également les points d’accroche rencontrés au fur et mesure de son élaboration qu’il ne fallait pas répéter sur ce nouveau projet. Son aide était donc précieuse.
Clément Marie, UI/UX Designer
Depuis son arrivée chez GuestToGuest, Clément nous aide à reconstruire visuellement l’application : expérience utilisateur, charte graphique, interactions, transitions, etc. Il était évident qu’il devait faire partie du processus de redesign de la nouvelle messagerie.
Mon seul regret est de ne pas avoir intégré nos développeurs mobile dans le processus dès le début. Ils auraient été d’une aide très précieuse pour comprendre certains fonctionnements propres à Android ou iOS et à adapter nos interfaces en conséquence.
L’équipe désormais constituée, il était grand temps de nous mettre au travail !
1. Jour 1 — Etapes préliminaires
Avant de foncer tête baissée vers la refonte de la messagerie de nos applications, il nous fallait délimiter correctement nos attentes, nos pistes d’amélioration et notre plan d’action.
Nos attentes étaient assez simples. Nous voulions une messagerie simple d’utilisation, belle et rapide et qui possède des fonctionnalités propres au mobile (utilisation du swipe, d’Apple Wallet…). Nous voulions également répondre aux attentes de nos membres qui désiraient des fonctionnalités déjà existantes sur notre site (comme la traduction des messages en langue étrangère). Dans le même temps, nos objectifs étaient très clairs : augmenter le nombre de demandes d’échanges entre nos membres, augmenter le nombre de messages entre eux, réduire le délai entre une demande et la finalisation d’un échange, et surtout augmenter le nombre d’échanges via nos apps.
Avec ces informations en tête, la critique pouvait commencer. Nous avons repris un par un les écrans qui constituent le workflow de notre messagerie mobile : de la prise de contact à la notation de l’échange, en passant par l’annulation de ce dernier. Pour chaque écran, nous notions ce qui n’allait pas — avec des post-its rouges — et ce qui pouvait être amélioré/modifié/ajouté — avec des post-its jaunes. Ce qui a fini par nous donner ceci :
Nous avons ensuite décidé de faire le benchmark de nombreuses applications pour voir ce qu’elles proposent en matière d’expérience utilisateur et de récupérer les idées les plus intéressantes pour la suite de notre process.
2. Jour 2 & 3 — Wireframing
Une fois que nous savions ce qui n’allait pas et ce que nous voulions, il était temps de commencer la refonte de la messagerie de nos applications.
Premièrement, nous avons remis à plat le workflow. Long et complexe, il nous fallait soit supprimer des étapes inutiles, soit en ajouter pour ajouter de la clarté à nos futurs écrans.
Deuxièmement, nous avons redessiné— avec un crayon et du papier — chaque écran de la façon suivante :
- Review des critiques, des attentes de nos membres et des idées intéressantes des autres applications concernant l’écran à redessiner.
- Chaque membre de l’équipe à deux minutes pour dessiner le nouvel écran en intégrant les remarques précédentes. Ce processus permet d’aller à l’essentiel et de ne pas passer trop de temps sur les détails. Seul le fonctionnement de l’écran compte à cette étape.
- Chacun présente son dessin et argumente ses choix devant les autres. Cette étape permet surtout de relever les incohérences du wireframe ou de creuser une bonne idée présentée.
- Fusion des dessins en gardant les bonnes idées de chacun pour créer un wireframe de l’écran. Dans les faits, cette étape était assez simple puisque chacun avait plus ou moins les mêmes idées de features, seule l’UX variait.
Troisièmement, nous avons passé en revue tous nos dessins et les avons présenté à nos collègues pour voir si l’UX fonctionnait bien. En fonction des retours que nous avons eu, nous avons adapté les écrans avant de passer à l’étape suivante.
3. Jour 4 — Des wireframes à l’UI
Le quatrième jour, nous avons laissé Clément travailler seul sur les maquettes. Nous avons fait ce choix pour garder une cohérence visuelle sur l’ensemble des écrans réalisés : travailler à trois nous aurait pousser à refaire des modifications par la suite pour homogénéiser l’UI, ce qui nous aurait fait perdre du temps inutilement.
Une fois tous les écrans finis, ils ont été animés via Invision et partagés en interne pour avoir des retours rapides. Ce process nous a permis de modifier nos maquettes en conséquence avant de réaliser des maquettes animées sur Principle pour obtenir un comportement aussi vrai que possible en vue de réaliser des tests auprès de nos utilisateurs.
4. Jour 5 — Tests utilisateurs
Dernière étape de notre Sprint Design : valider nos maquettes auprès de nos utilisateurs. Par chance, nous organisions une soirée avec nos ambassadeurs et nous pensions qu’il s’agissait du moment idéal pour avoir des retours pertinents.
Pour s’assurer de la pertinence des retours utilisateurs, nous avons découpé notre test en quatre phases qui correspondent à chaque étape de notre processus d’échange :
- Faire une demande d’échange
- Valider cette demande
- Obtenir des informations sur son hôte ou son invité
- Noter l’échange
Pour chaque phase, nous observions et notions la manière dont nos membres utilisaient l’application, puis nous leur demandions ce qu’ils avaient pensé de l’application et des nouveaux écrans, ainsi que de noter de 1 à 10 la clarté et la simplicité de nos nouveaux processus.
De manière globale, la refonte de notre messagerie mobile a été bien accueillie par nos ambassadeurs. Toutefois, tous s’accordaient à dire que certains écrans ou étapes du workflow étaient plus clairs qu’avant, mais pas forcément plus simples. Par la suite, nous avons modifié et approfondi la réflexion sur ces écrans et étapes afin de les rendre encore plus simples d’utilisation.
5. Les jours suivants
Au bout de cinq jours, nous avions réussi ! Nous étions parvenus à refaire l’une des pierres angulaires de notre application en simplifiant au maximum l’expérience utilisateur, en ajoutant des fonctionnalités demandées depuis longtemps par nos membres et en validant nos choix auprès de nos ambassadeurs et de nos membres.
Il ne nous restait plus qu’une étape : présenter les maquettes et les spécifications techniques aux développeurs mobile. Mais voilà, nous avions un problème : Alexandre, Clément et moi-même sommes de fervents utilisateurs d’iOS. En n’intégrant pas les développeurs mobile — et principalement Rémy, developpeur Android — au Design Sprint, nous n’adaptions pas nos maquettes et spécifications techniques à chaque plateforme, ce qui nous fait perdre du temps lorsqu’il a fallu refaire des écrans de zéro pour les adapter. Une fois ce léger contretemps réglé, le développement a pu commencer !
