Plaidoyer pour une refonte complète du produit

Persuader mon équipe de repenser le Fabric Crashlytics dans Firebase

Crashlytics dans Fabric (à gauche), Crashlytics redéfini dans Firebase (à droite)

J'ai récemment eu l'occasion de repenser Crashlytics, un outil de signalement des incidents qui permet aux développeurs d'applications mobiles de comprendre pourquoi leurs applications se bloquent. (Avez-vous déjà eu un blocage d'application sur vous? Crashlytics aide les développeurs à résoudre ce problème.)

Mon équipe a rejoint Firebase chez Google en janvier 2017 dans le cadre de l'acquisition de Fabric. L’un des objectifs de l’acquisition était d’apporter Crashlytics à Firebase. Cela impliquait de redéfinir et de reconstruire notre produit dans Firebase, qui utilise Material Design et possède un système de conception visuelle très différent.

Étant donné que nous avions besoin de mettre à jour la conception visuelle de Crashlytics, j'ai décidé qu'il s'agissait d'une excellente occasion de repenser l'expérience utilisateur dans son ensemble, plutôt que de simplement transférer les fonctionnalités telles quelles. Crashlytics est un produit bien-aimé, mais il avait accumulé beaucoup de dettes de conception depuis sa création en 2011. De nombreux utilisateurs nous ont dit qu'ils avaient des difficultés à utiliser les fonctionnalités ou ne parvenaient pas à trouver une fonctionnalité déjà disponible. Il devenait également difficile pour notre équipe de savoir où mettre les nouvelles fonctionnalités car le produit n’avait pas de hiérarchie d’informations claire - pour nous-mêmes et pour nos utilisateurs. Il était temps pour une refonte.

Mais avant, je devais construire mon dossier.

On ne commence pas simplement à redéfinir un produit. Il faut du temps pour comprendre les utilisateurs, comment ils utilisent votre produit et leurs problèmes. Il est essentiel d’obtenir toutes ces informations avant de se lancer dans la refonte pour s’assurer que l’équipe résout les bons problèmes et s’aligne sur les objectifs du projet.

Étape 1: Comprenez vos utilisateurs

J'ai commencé par collecter des informations. J’ai parlé à des coéquipiers de Crashlytics qui travaillaient sur le produit depuis de nombreuses années, à notre équipe de relations avec les développeurs, aux chercheurs utilisateurs et, bien sûr, à nos utilisateurs. Je devais comprendre pourquoi et comment les gens utilisent Crashlytics avant de pouvoir améliorer leur expérience utilisateur.

Heureusement, mon chef de produit, Jason St. Pierre, travaillait sur Crashlytics depuis plus de 5 ans et parlait souvent avec les utilisateurs. Il comprenait donc parfaitement comment un grand nombre de personnes utilisent Crashlytics. Il a identifié les 4 parcours utilisateur les plus critiques de Crashlytics:

  1. Contrôle de la stabilité d'une version d'application nouvellement publiée
  2. Vérification de la stabilité de l'application
  3. Prioriser les pannes à réparer
  4. Déboguer un problème client
Le parcours utilisateur le plus critique dans Crashlytics: surveiller la stabilité d'une version d'application récemment publiée

J'ai cartographié chacun de ces trajets d'utilisateurs dans des flux à l'aide de personas, ce qui a révélé un micro-trajet cohérent entre les quatre trajets: le flux «rechercher et réparer». J'ai partagé ces voyages avec l'équipe et révisé les flux au besoin. Ces flux ont aligné l'équipe Crashlytics sur une compréhension fondamentale commune de la manière dont les utilisateurs utilisent notre produit.

Le flux «rechercher et réparer» est un ensemble récurrent d'étapes franchies par un utilisateur au cours de ses 4 parcours utilisateur.

Étape 2: Comprenez leurs points de douleur

Une fois que nous avions défini la manière dont les gens utilisent notre produit, nous devions comprendre leurs difficultés avec l'UX existant. L’équipe de Crashlytics est extrêmement collaborative et nous sommes tous investis dans la création d’une expérience unique pour nos utilisateurs. Je voulais un moyen de les impliquer dans le processus de refonte, plus collaboratif que moi, en partageant les concepts et en obtenant leurs commentaires. L’équipe a également eu beaucoup de contexte précieux sur le produit qui pourrait être utile pour tirer parti de la refonte, car beaucoup d’entre eux travaillent sur le produit depuis des années.

De nombreux membres de l'équipe Crashlytics ont mentionné divers aspects du tableau de bord nécessitant des améliorations. Pour tirer parti de leurs connaissances, j'ai décidé de mener une série d'études internes auprès des utilisateurs. Mon objectif était de comprendre quels étaient les points les plus pénibles de l'expérience utilisateur - en fonction de ce que nous avions entendu de la part des clients au fil des ans.

J'ai imprimé et découpé le tableau de bord Crashlytics et mis en place des sessions individuelles avec des coéquipiers au cours desquelles je leur ai demandé de réorganiser les éléments et de redessiner le tableau de bord, en parlant à haute voix pour expliquer leur raisonnement.

Coéquipiers s'amusant à redéfinir Crashlytics avec des découpes de papierCertains des tableaux de bord redessinés - quelques personnes ont également ajouté de nouvelles fonctionnalités avec post-its

C'était extrêmement utile. Non seulement c'était amusant (à quelle fréquence les concepteurs numériques peuvent-ils jouer avec du vrai papier de nos jours?), J'ai également pu voir ce que chaque personne a identifié comme étant un point douloureux sans être biaisée par quiconque. Cela m'a permis d'identifier plus facilement des thèmes récurrents. Par exemple, chaque personne s'est concentrée sur l'amélioration des filtres et de la hiérarchie de l'information. L'équipe des relations avec les développeurs m'a également appris quelles fonctionnalités étaient difficiles à utiliser et à trouver.

J'ai partagé ces connaissances avec l'équipe dans un document récapitulatif qui répertorie les efforts de restructuration. J'ai également mis en place des contrôles de conception hebdomadaires avec l'équipe afin de partager les mises à jour de conception et de les accompagner tout au long du processus de refonte.

Une diapositive du processus de refonte décrivant les thèmes récurrents sur la page Présentation de Crashlytics

Étape 3: Définir les problèmes de l'utilisateur

Après avoir compris les objectifs et les difficultés de nos utilisateurs, les problèmes des utilisateurs sont devenus beaucoup plus clairs. J'ai pris tous mes enseignements tirés des séances de découpe de papier et des conversations avec les utilisateurs et l'équipe, puis je me suis concentré sur nos principaux problèmes d'utilisateur:

Problème 1: Les utilisateurs ont eu du mal à obtenir les informations qui les tenaient vraiment à cœur

La première chose que la plupart des utilisateurs ont faite sur notre tableau de bord a été de faire défiler l'écran. Les informations qu'ils recherchaient se trouvaient plus bas dans la page ou nécessitaient plusieurs clics pour y accéder. Il était enterré derrière des caractéristiques moins importantes.

La page de détail de la question dans Fabric Crashlytics

Problème 2: les utilisateurs ne savaient pas que les fonctionnalités existaient

Un jour, un utilisateur m'a demandé d'ajouter une fonctionnalité permettant de consigner ce qui s'était passé dans l'application avant un blocage. Cette fonctionnalité existait déjà dans notre tableau de bord - elle était simplement enterrée dans l'interface utilisateur. Notre équipe de support a également entendu de nombreux cas similaires d'utilisateurs. Ce problème reflétait également le problème rencontré par notre propre équipe: difficulté à savoir où placer les fonctionnalités.

La page de détail des sessions dans Fabric Crashlytics

Le thème général qui a émergé était que la hiérarchie de l’information de notre produit n’était pas claire, ce que j’ai présenté aux parties prenantes comme étant le principal problème à résoudre. Comme ils faisaient partie du processus de conception depuis le début, il était facile de s’aligner et d’obtenir l’adhésion.

Comment tout a fonctionné

L'équipe a officiellement accepté la nécessité d'une refonte. Ils ont compris les problèmes rencontrés par les utilisateurs et ont convenu des éléments de l'expérience utilisateur à améliorer. Succès! Les prochaines étapes consistaient à redéfinir le tableau de bord, ce qui a été fait au cours des prochains mois grâce à de nombreuses séances de brainstorming, de collaboration, d’archivages et de tests utilisateurs.

Construire un dossier pour une refonte implique une tonne de paramètres de contexte. En tant que concepteur, vous comprenez peut-être qu'un produit a besoin d'une refonte, mais vous ne pouvez pas aller loin tout seul. Une refonte du produit est un travail d’équipe et il est important que l’équipe comprenne pourquoi une nouvelle conception est nécessaire. Il est également impossible de redéfinir quelque chose si vous ne comprenez pas comment il est actuellement utilisé.

En comprenant profondément les utilisateurs de Crashlytics, leurs points douloureux et leurs problèmes, j'étais beaucoup mieux équipé pour redéfinir le produit. Et en faisant participer les autres à ce processus, l’ensemble de l’équipe a pu mieux comprendre nos utilisateurs et répondre à leurs besoins. Après des mois de travail acharné et de discussions avec les utilisateurs, nous avons lancé avec succès une refonte de Crashlytics dans Firebase plus tôt cette année, proposant une hiérarchie améliorée des informations et une actualisation visuelle, ainsi que de nouvelles fonctionnalités!

Pour conclure, voici ma partie préférée de la refonte de Crashlytics:

Une animation festive lorsqu'un utilisateur corrige un bogue avec succès!