L'art et la science des annotations dans Dev Mode

J’aime autant que je déteste annoter un fichier Figma. Je mets un point d'honneur à ajouter les touches finales à un design, tout en veillant scrupuleusement à ce que toutes les spécifications et mesures soient respectées. Il peut s’agir d’ajouter une note de texte, une flèche, une courte légende ou du contexte supplémentaire pour expliquer le choix de ce design et détailler le design lui-même. Annoter un fichier peut donner l'impression de perdre son temps, même si cela peut faire une grande différence dans le processus de développement des produits. Tandis que les designers passent du temps à rédiger, illustrer et organiser manuellement un fichier pour s’assurer que chaque exigence de design est bien prise en compte, les développeurs passent autant de temps à essayer de comprendre ces designs, à en saisir le contexte et à assimiler les exigences requises pour donner vie au concept.

Ces exigences non visuelles sont souvent réparties entre différents fichiers et outils, qu’il s’agisse d’un document d’exigences produit ou d’un fichier de design. Nous voulions créer des annotations de manière à ce que le contexte se trouve dans un seul et même endroit (spécification complète directement dans Dev Mode) et soit adapté aux cas d’utilisation des designers et et des développeurs.

Lors de la définition de la fonctionnalité, nous avons entrepris de résoudre quelques problèmes clés, en vue de rapprocher le design et le code : les annotations peuvent non seulement prendre du temps, mais aussi devenir rapidement obsolètes et encombrer les fichiers de design.

Répondre aux besoins des designers et des développeurs

Pour nous guider dans notre travail, nous avons pris un peu de recul pour réfléchir au rôle des annotations dans le processus de design (quel est-il aujourd’hui et comment peut-il évoluer ?), en tenant compte des retours des designers et des développeurs.

Pour les designers, les annotations traitent souvent des qualités de design qui ne transparaissent pas dans le design lui-même. Qu’il s’agisse de propriétés d’accessibilité ou d’un comportement interactif détaillé, les designers ont besoin d’un espace où indiquer ces attributs.

Pour les développeurs, partager un design et partager une tâche d’ingénierie spécifique sont deux choses totalement différentes. L’un des principaux défis qu'ils rencontrent est de trouver l’aiguille dans la meule de foin. Souvent, les fichiers de design contiennent tellement d’informations et demandent tellement de travail qu’il est difficile de savoir sur quoi se concentrer. L'organisation est une partie importante du processus de design.

Ces différents besoins et défis ont précisé le rôle exact des annotations dans Dev Mode. En interne, nous avons beaucoup débattu à ce sujet. Il est possible d'utiliser les annotations à plusieurs étapes du processus de design, mais la priorité était de rapprocher les workflows des designers et des développeurs, tout en résolvant les difficultés uniques qu'ils rencontrent.

Nous voulions un espace dédié permettant d'ajouter une spécification pour les développeurs et de signaler des détails nécessaires ou des zones de confusion. Nous avons donc décidé que les designers devraient utiliser Dev Mode pour annoter des fichiers, leur permettant ainsi de voir la même chose que leurs homologues développeurs. Une fois leur travail terminé, ils pourraient également partager un lien vers Dev Mode. Avec Dev Mode, notre objectif n'est pas de cloisonner les développeurs une fois le travail des designers terminé, mais d'impliquer toute l'équipe dans le processus de développement des produits, les annotations représentant une première étape cruciale.

La puissance des modifications dynamiques

Une fois notre approche globale établie, nous nous sommes penchés sur d'autres décisions de design clés. Jusqu'à présent, les designers devaient créer les annotations manuellement, ces dernières n'étant alors pas synchronisées avec les modifications apportées aux designs. Ce processus fonctionne lorsqu'il ne reste à un designer qu'à marquer un design comme étant « prêt pour le développement ». Toutefois, le caractère toujours actif du développement des produits requiert le plus souvent une communication constante et claire lorsque les designers travaillent sur plusieurs itérations et que les développeurs ont besoin d'un moyen simple d'assurer le suivi des modifications.

Lors d'un des premiers sprints de design, nous nous sommes posé la question suivante : « Et s'il existait un moyen de connecter les annotations aux propriétés d'un design ? ». Les designers n'auraient plus à répliquer manuellement les détails d'un design lorsqu'ils annotent des fichiers, les annotations se mettant à jour à mesure de l'application des modifications du design. Les développeurs sont ainsi sûrs que les annotations qu'ils voient sont à jour avec le design le plus récent, même si leur homologue design y apporte activement des modifications.

Nous avons appliqué la même idée aux mesures : lorsque le design change (ce qui est inévitable), pourquoi la ligne que vous avez dessinée pour marquer une dimension ne changerait-elle pas également ?

Il ne s'agit pas uniquement de ce qui a été modifié dans un design. Les notes de texte simple laissent beaucoup de place aux erreurs. Cependant, lorsque les annotations peuvent faire référence à des variables et composants réels d'un design system, les développeurs sont sûrs que la spécification est alignée sur la base de code.

Notre logique de positionnement

Grâce à des recherches et à notre expérience personnelle, nous savions que, jusqu'à présent, les designers avaient la lourde tâche de déplacer les cadres pour libérer de l'espace pour les annotations. Plus ils ajoutent des annotations, plus ils doivent réorganiser les cadres sur le plan de travail pour placer le contexte au bon endroit. Nous nous sommes demandé s'il existait un moyen pour que les annotations soient suffisamment visibles pour les développeurs sans qu'elles ne prennent trop de place sur le plan de travail Figma.

Notre idée de positionner et d'afficher automatiquement les annotations était prometteuse. Même si cela changeait totalement la méthode actuelle d'annotation des fichiers, si nous y parvenions, les designers n'auraient plus eu à remanier constamment leur fichier et l'expérience des développeurs en aurait été simplifiée. Mais cela n'était pas une mince affaire, des douzaines de prototypes et d'itérations étant nécessaires. De nombreuses interactions étaient en jeu : zoom, panoramique, mise à l'échelle, réduction, sélection et pointage.

Notre équipe d'ingénierie a pris l'initiative d'ajuster notre logique d'affichage pour s'assurer qu'il en ressortirait une excellente expérience. Lors d'une première démonstration de bout en bout de Roshan Bhalla, ingénieur logiciel, l'équipe a vraiment commencé à voir la vision se concrétiser.

Au début, nous avions prévu de positionner les annotations en dehors du cadre supérieur du support annoté. Les utilisateurs de la version bêta nous ont indiqué qu'avec cette approche, les annotations étaient alors trop décalées lorsque les designers utilisaient des cadres imbriqués. Pour régler cela, nous avons apporté quelques modifications :

• Nous avons défini une distance maximale à laquelle une annotation peut être décalée de ce qu'elle décrit.
• Nous avons fait en sorte que les annotations ne puissent plus sortir du cadre de votre fenêtre de façon à ce qu'elles soient toujours visibles lorsque vous effectuez un panoramique.

Mais nous ne nous sommes pas arrêtés là. En nous basant sur les commentaires reçus suite à la version bêta et à un test interne, nous avons testé plusieurs autres approches, dont celle du positionnement basé sur la physique :

Les tests et itérations réalisés sur notre logique de positionnement ont apporté leur lot de défis. Nous avons testé une idée qui consistait à masquer les annotations tant qu'on ne cliquait pas sur le cadre correspondant. En théorie, l'idée semblait bonne. Toutefois, lorsque nous l'avons essayée, nous nous sommes rendu compte qu'il était facile de passer à côté de certaines annotations importantes si on se contentait de regarder un cadre sans le sélectionner.

Lorsque nous avons ensuite réalisé des itérations sur différentes versions d'annotations qui se développent automatiquement selon leur niveau de zoom ou leur position, tout a semblé tout de suite plus intuitif. Nous avons alors ajouté un curseur temporaire à l'interface utilisateur qui nous a permis de définir différents paramètres de zoom afin de trouver le « bon » niveau. Améliorer ces interactions a joué un rôle sur le ressenti du système dans son ensemble.

Les améliorations apportées pour accélérer les annotations et les connecter au design les valorisaient de manières fondamentalement différentes. Cependant, nous savions aussi que presque toutes les équipes auxquelles nous avions parlé avaient chacune une façon différente d'intégrer les annotations à leur workflow et de les présenter. Certaines considéraient les annotations comme des tâches ou des exigences qu'il fallait suivre et connecter aux outils de gestion des tâches.

Au vu des perspectives d'avenir, nous sommes ravis d'avoir également adopté une approche axée sur l'extensibilité. Les équipes peuvent ainsi créer leurs propres workflows concernant la fonctionnalité d'annotation de Figma, à l'aide de l'API de plugin. Des informations supplémentaires à ce sujet seront bientôt disponibles.

Les annotations ne sont qu'une partie de l'équation

Nous sommes ravis non seulement de lancer des annotations suite aux nombreux commentaires des utilisateurs, mais aussi de faire de Dev Mode le point central des spécifications de design. Ainsi, les designers peuvent faire part de leurs intentions et les développeurs peuvent avoir à leur disposition le contexte dont ils ont besoin, le tout dans un seul et même endroit.

Nous espérons que les annotations dans Dev Mode aideront les designers et les développeurs à mieux communiquer les moindres détails de leur travail. Nous reconnaissons également que les annotations ne sont pas la seule solution pour améliorer les communications entre ces rôles critiques. Elles ne représentent qu'une partie du processus qui nous semblait important de simplifier. Nous sommes donc ravis de continuer à explorer les autres éléments de la collaboration entre designers et développeurs, tout en faisant évoluer Dev Mode. Nous avons hâte que vous nous fassiez part de vos attentes.

Cliquez ici pour en savoir plus sur les nouveautés du jour et à venir de Dev Mode.

Nous tenons à remercier les différents membres du groupe de travail de Figma : Benson Perry, responsable produits, Ed Bentley, Roshan Bhalla, Jenny Lea, Karl Jiang et Sue Hitchins, ingénieurs, Noga Mann, responsable ingénierie, Molly Jane Nicholas, chercheuse, et Collin Wiles, spécialiste des données.