Le contrôle de versions pour les designers

I – Qu’est-ce que la gestion de versions ?

La gestion de versions ou en anglais “Version control” est un outil permettant de gérer et de suivre les différentes versions d’un ou plusieurs fichiers.

Il est à ne pas confondre avec l’historique de version (“Version history” en anglais) qui consiste à historiser de manière linéaire les évolutions sur un fichier.

Nous nous en servons naturellement au quotidien avec des outils comme Notion, Miro ou encore les fichiers partagés de la suite Office ou de la suite Google. Cela permet de voir qui apporte une modification au fichier et sa date d’ajout.
Il y a néanmoins des limites, la modification qui a été réalisée va, à terme, se noyer dans une masse de modifications et le contexte de celle-ci sera perdu. De plus, s’il y a le besoin de revenir à une modification précise, tout le contenu entre cette modification et la toute dernière sera perdu. Ce qui posera problème sur une équipe de plusieurs designers travaillant sur le même fichier.

Tandis que le contrôle de versions va au-delà de l’historisation. Avec il y a la possibilité de décider ce qui doit ou non être présent dans le fichier, il est possible de supprimer ou d’ajouter uniquement une mise à jour choisie, c’est-à-dire une version.

Cela est rendu possible grâce aux branches. Elles permettent de travailler sur un espace dédié, indépendant de celui des autres designers et du fichier source.
De plus c’est à l’auteur de la branche de décider si oui ou non il fusionne (merge) le travail réalisé sur une de ses branches avec le fichier principal. Pratique non ? Cela améliore nettement le travail d’équipe sur un seul et même fichier.

II – Pourquoi l’intégrer dans un processus de Design ?

Bien qu’étant très efficace, il a longtemps été difficile d’appliquer le contrôle de versions dans les processus de design.
En effet, nos fichiers sont trop volumineux pour pouvoir être utilisés avec des outils comme Git ou SVN. Il a pendant de nombreuses années fallu les dupliquer (qui se souvient des final_final_3.psd) ou encore les stocker, avec les nombreux exports jpg dans des outils en cloud comme Dropbox ou Google Drive pour diminuer le risque de les perde et pouvoir les partager avec les autres designers, les développeurs ou encore les chefs de projet.
Combien de fois avez-vous eu cette appréhension en ouvrant un fichier modifié par un autre designer ?

Fort heureusement, les outils ont évolués et de nouveaux acteurs sont arrivés avec le temps. Ce qui a apporté un gain non négligeable dans la fluidité du travail et des échanges. Exit les fichiers final, final_V3, final_final_V2 ; exit les exports massifs de jpg envoyés par mail pour validation ; exit les transferts de fichiers sources pour passer la main à un autre designer ; exit les fichiers cassés ; exit les fichiers devenus désordonnés et tant d’autres processus chronophages.

Ces outils (comme Abstract ou Figma pour ne citer qu’eux) permettent d’intégrer la gestion de contrôle dans les processus. Ce qui apporte de nombreux avantages signifiants :

• Mieux travailler en équipe
  Fini de jongler avec de nombreux fichiers, un seul suffit. Toute l’équipe peut travailler de manière collaborative dessus ! De plus avec la notion de branche, chacun peut avoir son environnement, sans impacter le travail des autres. Tout y est centralisé.
• Mieux communiquer
  Via un fichier unique ne contenant que les versions finalisées et validées il est plus simple de partager les interfaces aux équipes et de communiquer au quotidien. Pas besoin d’envoyer de nombreuses images, tout tient sur une URL, que cela soit les maquettes ou les prototypes.
• Diminution du facteur bus
  En effet, il est plus simple de garder les connaissance institutionnelles et de les partager avec les nouveaux entrants. Le suivi peut être dissocié plus facilement des membres de l’équipe grâce à l’historisation du travail et le stockage en ligne des fichiers.
• Garder ses fichiers structurés et organisés
  Via le processus de gestion de versions, vous ne fusionnez avec votre fichier principal que les évolutions actées et validées, c’est-à-dire respectant les conventions de nomenclature, de version, de qualité etc. Fini donc les calques mal nommés, vide ou tout élément inutile.
• Mieux suivre les évolutions et les dépréciations
  Avec l’usage de la gestion de versions vos évolutions sont loties et nommées. Il est donc assez aisé de suivre les évolutions du produit mais aussi les dépréciations d’éléments (comme un composant de Design System par exemple).
• Tester encore plus d’idées
  Via le principe de branches vous pouvez tester tout ce que vous voulez sans écraser le travail des autres ou devoir faire plusieurs fichiers. De plus vous pouvez récupérer le travail réalisé sur le fichier général pour toujours être à jour avec les évolutions.
• Limiter les erreurs
  Comme vous ne fusionnez avec votre fichier principal que ce qui est bon et validé, vous limitez les erreurs présentes. De plus il y a une limitation du risque d’écrasement du travail par un autre ou de modifications subies et non choisies.
• Gagner en productivité
  En effet, vous allez gagner en temps et en rigueur. Ce temps gagné va pouvoir servir à mieux vous concentrer sur vos tâches et moins sur de la résolution de conflits ou de l’organisationnel.

En bref, la prise en compte du contrôle de versions dans le processus de travail devrait être systématique sur les produits nécessitant plusieurs designers.

III – Quelques bonnes pratiques

Intéressons-nous maintenant à quelques bonnes pratiques permettant une utilisation aisée du contrôle de versions dans le processus de design. La liste n’est pas exhaustive mais c’est un bon début pour se lancer dans cette nouvelle façon de travailler de manière un peu plus sereine.

Versionner avec le SemVer

Nommer vos versions avec le SemVer est plus qu’utile. Cela vous aidera à suivre et à documenter les évolutions.
En effet, plus votre système va se développer, plus il y aura de dépendances entre les éléments, plus il y aura de parcours, plus il y aura d’évolutions qui impacteront l’existant. L’objectif est de permettre de suivre clairement ces évolutions et de pouvoir incrémenter la version à chaque ajout.

Nommez vos branches

Une bonne chose, c’est que vous pouvez créer autant de branches que vous le souhaitez, alors ne vous en privez pas. Cependant attention ! Nommez-les correctement, soyez clair et précis avec la nomenclature. Pas besoin d’un roman ou d’un long texte mais quelques mots qui définissent la branche.

Pour le nommage des branches il est intéressant de se baser sur ce qui existe chez les développeurs comme par exemple (non exhaustif) :

• [feature] : Ajout d’une nouvelle fonctionnalité ;
• [bugfix] : Correction d’un bug graphique ou fonctionnel (sur un composant par exemple) ;
• [update] : Mise à jour sur une feature ou un composant (dans le cas d’un Design System) ;
• [experiment] : Expérimentation des fonctionnalités.

N’hésitez pas à utiliser des termes qui vous font sens et à vous approprier ce principe.

Faites des commits réguliers

Voyez le commit comme la sauvegarde d’une brique de votre travail, un instantané des changements apportés. Vous avez votre branche et celle-ci peut être “découpée” en plusieurs commits. Chacun représentant un élément fonctionnel. De plus, à chaque commit est associé à un message, celui-ci doit être clair, concis et sans ambiguïté.

Comme pour les branches une nomenclature existe déjà côté développement, il est intéressant la aussi de récupérer ce qui fait sens pour vous et de l’agrémenter si besoin.

Voici des exemples (non exhaustif) :

• [feat]: Ajout d’une nouvelle fonctionnalité ;
• [fix] : Correction d’un bug ;
• [docs] : Ajout ou modification de documentation ;
• [refactor]: Modification n’ajoutant pas de fonctionnalités ni de correction de bug, comme le renomage ou la réogarnisation de vos calques, une suppression d’éléments inutiles, un changement sur la construction de votre composant, etc ;
• [prototype] : Ajout d’un prototype.

Utilisez la prévisualisation avant de valider un commit

Certains outils comme Abstract ou Figma vous permettent d’avoir une prévisualisation des changements, c’est-à-dire de comparer la version du fichier source avec votre version actuelle. Prenez le temps de regarder les changements (ou demandez à ce qu’on le fasse pour vous) afin d’être sûr que seules vos modifications soient prises en compte.

Ne fusionnez pas n’importe quand

Ne fusionnez pas votre branche avec le fichier source à la volée ! Suivez les protocoles mis en place par votre organisation, prévenez les membres de votre équipes et faites la fusion à des moments précis et propices. Si vous avez un DesignOps, c’est avec lui qu’il faudra s’en occuper. N’oubliez surtout n’oubliez jamais de COMMUNIQUER et de PARTAGER avant de fusionner. Cela évitera bien des erreurs.

IV – Conclusion

Bien que le contrôle de versions existe depuis de nombreuses années, il reste peu utilisé par les designers.

Historiquement il était presque impossible d’utiliser des outils comme git (fichiers trop volumineux) et nos logiciels ne nous permettaient pas de travailler à plusieurs sur un seul fichier. Néanmoins la donne a changé aujourd’hui. Il y a une pléthore d’outils nous permettant de faire du contrôle de versions.

Cependant, il faut garder à l’esprit qu’utiliser le contrôle de versions n’est pas une fin en soi dans un processus de design mais un outil qui nous permet de mieux travailler, partager et communiquer. Si vous êtes un “solo designer”, une toute petite équipe ou sur un projet qui ne nécessitera pas de re-travail alors utiliser ce processus peut être chronophage voir inutile. Au contraire si vous êtes nombreux, que votre équipe va grandir, que votre produit va évoluer, alors utiliser la gestion de versions vous fera gagner en fluidité dans les échanges, vous permettra de mieux suivre et gérer l’évolution du produit. La documentation et la collaboration n’en seront que plus efficace.