Bienvenue au pays du work in progress

Au cours de ma carrière, j'ai eu l'occasion de faire passer des entretiens à de nombreux designers et product managers. Lorsque je demandais aux candidats de m'expliquer comment s’était passé un de leurs projets, presque à chaque fois, ils me racontaient plus ou moins la même histoire.

En général, ils commencent par évoquer la phase de recherche, puis l'équipe se réunit pour un brainstorming géant (sans oublier les incontournables Post-it). S'ensuit alors une série de croquis dessinés à la main, le tout aboutissant à un prototype parfait au pixel près, qui fera l'objet de tests avant d'être dévoilé au monde entier. Tout simplement !

De la conception à l'aboutissement du projet, quelle belle histoire à raconter !

Je dois vous avouer que j'y crois rarement. De nos jours, les produits ne sont pas créés d'une façon aussi claire, linéaire et idéale. La réalité est bien plus compliquée. Alors pourquoi prétendre le contraire ?

À vrai dire, pendant longtemps, les choses se passaient réellement comme cela. À l'époque où le design produit concernait uniquement des produits physiques, chaque personne impliquée devait suivre un processus linéaire soigneusement élaboré. Au fur et à mesure de la numérisation du monde, le rythme de l’itération et de la création s’est accéléré. Au lieu de laisser les utilisateurs avec le même design pour les années à venir, les équipes produit peuvent désormais livrer une mise à jour en quelques minutes. Aujourd'hui, chaque produit numérique est un travail en cours, et cela a modifié jusqu'à la façon dont nous concevons les interfaces.

Notre travail ne semble jamais terminé car il ne l'est jamais véritablement. Nos collaborateurs entrent et sortent les fichiers, laissent leurs commentaires et itérent sur des designs alors que nous les créons. Beaucoup d'entre nous peuvent livrer à n'importe quel moment, il est donc désormais difficile de savoir quand les nouveaux designs sont vraiment prêts. Telle est la réalité chaotique du design et du développement de produits d'aujourd'hui. Chez Figma, nous passons beaucoup de temps à y réfléchir, à nous demander comment s'y retrouver et comment créer dans ce contexte. Voici des solutions que nous avons trouvées efficaces, ainsi de nouvelles fonctionnalités conçues pour améliorer le reste du processus.

Les fichiers ne sont plus des documents figés que l'on envoie en pièce jointe d'un e-mail à nos collaborateurs. Les outils accessibles via les navigateurs permettent de partager son travail avec tout le monde et partout avec une simple URL, afin que chacun puisse visionner le même fichier et y travailler simultanément.

Il s'avère que, lorsque les personnes peuvent itérer sur leur travail en temps réel, elles le montrent plus tôt aux autres. Si vous avez déjà ajouté la mention « WIP » ou « Travail en cours » au titre d'un fichier, vous avez conscience du sens de la démarche. Cette précision permet de diminuer l'enjeu, et de signaler à tout le monde qu'il s'agit d'un travail qui n'estpas encore terminé. Les designers peuvent faire part de leurs orientations initiales aux product managers, tout comme les écrivains partagent leur premier jet avec leurs éditeurs. Bienvenue au pays du WIP, ou travail en cours.

Avancer au pays du WIP

Ainsi, plus les retours interviennent tôt dans le processus, plus on avance rapidement. Tout va mieux dans le meilleur des mondes, n'est-ce pas ? Cependant, quand tout relève du travail en cours, ni l'énoncé du problème, ni sa solution, ni le produit lui-même ne peuvent être considérés comme terminés. C'est pourquoi, les processus rigides et leurs étapes bien déterminées ont laissé place à davantage de fluidité et de spontanéité.

Lorsuq'un document en évolution est ouvert, les collaborateurs peuvent y accéder dès qu’ils le souhaitent et ajouter leurs retours. Mais les commentaires peuvent devenir obsolètes au fil de l'évolution (inévitable) du projet. Ou alors, ce que vous aviez validé tel jour est complètement différent le lendemain, car le travail n'était pas achevé. Rester dans la boucle devient alors essentiel. Nous avons donc mis en place de nouvelles notifications et de nouveaux commentaires mobiles, afin de dissiper certaines confusions (et de permettre de répondre plus facilement en déplacement). Étant donné qu'il peut être encore difficile d'assurer la connexion au workflow, nous continuons à rechercher de nouvelles intégrations et extensions telles que l'extension Figma sur Chrome qui permet de relier des fichiers à des événements Google Agenda, ou des fonctionnalités qui permettent de collaborer directement dans Microsoft Teams et Zoom.

Toutefois, il n'existe toujours pas de moment précis où un fichier est définitivement terminé. En réalité, les gens oublient souvent d'enlever la mention « Travail en cours », même une fois arrivés au stade de la livraison du produit. De nouveaux repères s’avèrent nécessaires pour s'orienter dans ce monde à la fois chaotique et plein de potentiel du travail en cours. Alors, comment faire réellement avancer un projet ?

Passer en revue le travail à un rythme prédéfini, plutôt que d'attendre le moment idéal

Quand le travail est constamment en train d'évoluer, difficile de trouver le bon moment pour demander l'avis des parties prenantes ou de la direction. Chez Figma, j'essaye toujours de déterminer quel est le moment opportun pour me pencher sur le travail de mon équipe. Devrais-je le faire une fois le problème bien délimité ? Ou quand la solution est trouvée ? Ou bien lorsque le produit est prêt à être livré ? Dans l'idéal, on fait soigneusement passer le projet d'étape en étape. Nous passons en revue la travail au moment idéal et cela nous conforte dans nos choix concernant la direction que prendra le produit.

Cependant, comme nous l'avons déjà expliqué, la progression est rarement aussi linéaire. Au cours de la phase d'exploration, le problème peut évoluer, ou vous pouvez continuer à itérer et mettre au jour une nouvelle direction. D'autres parties du produit peuvent évoluer dans des directions différentes, d’où d’éventuelles difficultés à repérer le bon moment pour partager et montrer votre travail. Lorsqu'on ne partage pas son travail, plus le temps passe, et plus les enjeux augmentent, tout comme le stress et la possibilité de soucis d'alignement.

Chez Figma, les critiques de design

régulières constituent la solution idéale. Le mardi et le jeudi, des collaborateurs partagent leur travail, quel qu'en soit l'état ou le stade d'avancement, afin d'obtenir des retours de leurs pairs et des parties prenantes. Cette pratique est plus judicieuse car elle permet aux collaborateurs de connaître l'avis des parties prenantes chaque semaine et de les faire itérer ou rectifer le tir.

Pour moi, cette façon de faire est vouée à s’imposer. Il est plus efficace d'examiner régulièrement des travaux quel que soit leur état, plutôt que d'attendre un moment opportun qui n'arrivera jamais.

Donner un feedback : la forme est aussi importante que le fond

Quand on opère de cette façon, il est difficile de savoir comment formuler des retours, surtout en tant que collaborateur ou partie prenante. Bien qu'il soit passionnant de suivre l'évolution d'un projet en temps réel, étant donné que les travaux peuvent changer à tout moment, il est difficile de déterminer le type et le niveau de retour à formuler. (Note du rédacteur : si vous ne savez pas comment offrir le meilleur retour à l'un de vos proches pour les fêtes, consultez le Guide du feedback selon Figma

.)

Vous partagez peut-être vos premières ébauches avec les membres de votre équipe, en espérant des idées ou des orientations utiles. Au début, cette pratique est plutôt intéressante, car les réactions sont constructives. Mais assez rapidement, des curieux viennent apporter leur grain de sel et les commentaires s'accumulent. Pire encore, des personnes (notamment en haut de la hiérarchie), ouvrent le fichier sans vraiment connaître le contexte, ajoutent un commentaire, puis disparaissent. Ce phénomène est communément appelé le « swoop and poop » (ou le fait de lâcher une bombe avant de disparaître du paysage). Vous vous retrouvez alors face à une nouvelle série de commentaires à traiter – une expérience qui peut s’avérer décourageante.

J'ai récemment appris une astuce de pro pour cadrer les retours tout en recevant des avis de haut niveau. Notre équipe marketing doit souvent partager de longs textes, tels que des articles de blog. Auparavant, ces collègues envoyaient un lien aux parties prenantes via Google Docs ou Dropbox Paper, et recevaient une longue liste de commentaires et de suggestions de modification. Pour changer, ils ont commencé à partager leurs brouillons en tant que captures d'écran dans FigJam. D'autres personnes pouvaient alors faire des retours sous forme de notes, utiliser la fonction surligneur pour ajouter des annotations, et exprimer toute sorte d'émotions, le tout sans que l'auteur du projet ne soit obligé d'y répondre ou d'apporter des solutions. Ce modèle permet aux parties prenantes de contribuer au projet sans ralentir ou bloquer l'équipe.

Bien que les retours de ce genre soient bien différents d'une intimidante liste de commentaires intimidante dans Google Docs, ils soulèvent toutefois un autre défi : comment faire ressortir les retours importants afin de s'assurer qu'ils ne soient pas perdus ou ignorés ?

Ce genre de choses arrive sans arrêt, surtout lorsque les commentaires sont ponctuels et que les designs sont encore en train d'évoluer. Lorsque je travaillais sur l'application client d'Uber, mon équipe a eu l'idée d'initier le parcours de réservation en imposant à l'utilisateur de renseigner sa destination au préalable. Cette idée a été lancée assez tôt et une personne de l'équipe de recherche a signalé des retours critiques venus de nos collègues en Inde. Tout au long de l'avancée du projet, le commentaire subsistait dans le fichier, mais personne ne l'a traité. Le produit a été livré sans que le retour ait été pris en compte. Au final, nous avons dû résoudre le problème plusieurs semaines après le lancement.

Il est parfois difficile d'entendre et de traiter en priorité les retours essentiels. Il y a quelques mois, j'ai assisté à un dîner organisé par Shishir Mehrotra, co-fondateur et PDG de Coda, sur le thème des « rituels ». J'ai pu découvrir le concept de « flashtags » grâce au co-fondateur de Hubspot, qui permet aux dirigeants d'entreprise de préciser le niveau d'importance de leur retour. Il s'agit d'un hashtag ajouté à la fin de leur commentaire, qui indique le degré d'importance qu'il a pour son auteur, ou à quel point ce dernier est prêt à défendre son point de vue.

Par exemple :

• #fyi signifie « Je n’ai aucune intention de me battre ».
• #suggestion signifie « L'enjeu existe mais je n'y suis pas assez attaché pour me battre. C'est à prendre ou à laisser. »
• #recommendation signifie « Bien que l'enjeu soit important pour moi, après réflexion, je ne suis pas prêt à tout pour le défendre ».
• Et enfin, #plea signifie « Je me battrai jusqu'au bout. » Si vous voyez ce flashtag, traitez-le en priorité ! !
  

Ainsi, que l’on copie-colle des captures d'écran dans FigJam ou que l’on utilise des flashtags, il existe différents moyens de communiquer un retour en spécifiant son niveau d'importance. Il vous suffit d'utiliser ces variantes au bon moment pour influencer le projet de la bonne façon.

Soyez moins pointilleux sur ce qui est livré

Enfin, je souhaiterais aborder la question de la livraison dans un contexte où le travail est perpétuellement en cours. Tout comme pour les retours, nous savons rarement à quel moment nous sommes fins prêts à livrer. Les designs pourraient toujours être améliorés, il est donc tentant de continuer à y travailler. L'idée d’une réunion de lancement parfait, pendant laquelle toutes les cases peuvent être cochées avant la sortie du produit, est illusoire. Si c'était le cas, cela ne ferait que ralentir le travail et annuler les avantages de l'itération constante. Nous devons lâcher prise et nous faire à l'idée que le produit livré sera légèrement différent des designs vus ou évalués à la dernière réunion.

Tous les lancements ne seront donc pas parfaits. Toutefois, les clients ne jugent pas nos produits uniquement à ce moment précis.

Après tout, il est encore possible d'améliorer un produit après son lancement. J'ai adoré regarder l'équipe de The Browser Company créer son produit Arc en public. Lorsque leur head of design Dustin Senos a partagé une vidéo où il demandait des retours, il a reçu des centaines de réponses contenant des maquettes, des prototypes et des idées d'amélioration pertinentes. Lorsque nous invitons les gens à participer, ils se sentent concernées et s'investissent. Grâce à cela, les résultats sont bien meilleurs.

Vous seriez surpris du nombre de clients qui veulent vraiment participer au développement et à l'amélioration des produits. J'ai pu le constater avec les chauffeurs Uber : lorsque j'en ai invité un petit groupe à nous aider à réinventer le design de leur application, nombreux sont ceux qui nous ont envoyé des suggestions d'amélioration. C'est la même chose avec les designers de la communauté Figma, qui souhaitent participer à chaque version bêta et qui donnent continuellement leur avis dans l'espoir d'influencer notre roadmap. Nos utilisateurs préfèrent, et s'attendent même, à un produit qui s'améliore constamment, non à un produit tout juste « satisfaisant » mais qui n'évolue jamais.D'où ce dernier conseil : soyez moins pointilleux envers le travail livré, car il y aura une attente, et même des opportunités d’amélioration.

Bienvenue au pays du WIP

Cette nouvelle manière de travailler est chaotique, car elle remet en question toutes les hypothèses et les bonnes pratiques. Mais elle est également libératrice, en ce qu'elle semble plus adaptée au véritable processus créatif.

Malgré mon goût pour l'itération constante, je me sens parfois un peu perdu ou en perte de contrôle. Mon propre parcours au pays du WIP est un travail en cours en lui-même. C'est pourquoi je vais continuer à itérer sur cette idée au grand jour sur la Communauté Figma, où vous pourrez suivre mes avancées.