logo_figma_post-it-validation_review

Sketch-Invision vs. Figma

Après plusieurs longs mois de résistance, nous sommes définitivement passés sur Figma, et c’est indéniable c’est un outil infiniment plus confortable que Sketch pour notre équipe.

Travailler à plusieurs sur un même fichier, pouvoir corriger simplement une faute d’orthographe sans avoir à passer par du ticketing, maintenir une librairie facilement et impacter plusieurs projets en même temps… Quel bonheur quand on est sur une phase de réalisation de wireframes ou d’UI design !

Mais changer de logiciel a aussi impacté notre process dans nos échanges avec nos clients, et c’est vraiment le gros point noir de Figma.

Le process de validation remis en jeu

Le couple Sketch / Invision : puissance de validation incroyable

Si Sketch était perfectible, le couple Sketch Invision offrait vraiment beaucoup de puissance dans un process de validation pour les raisons suivantes :

  1. Maîtrise de ce qui est montré au client sur Invision On n’est pas obligé de mettre tous les artboards à disposition, on peut stabiliser, échanger au sein de l’équipe UX/UI avant de présenter
  2. Maîtrise de quand on montre ce qui est prêt au client Dans notre métier on parle beaucoup de charge cognitive, mais la charge cognitive de nos clients n’est pas toujours ménagée, surtout dans les gros projets ! Il y a des moments ou l’on peut ajouter plus d’artboards à faire valider, et d’autres où l’on va juste faire paniquer l’équipe projet en face !
  3. Un système de ticketing bien huilé Pouvoir créer des types de tickets était une vraie feature utile d’Invision. Quand sur une maquette on a des échanges sur l’UI, le SEO, l’intégration… et de nombreux interlocuteurs, avoir un filtrage par type de commentaires est un véritable life changer. Ainsi, chaque corps de métier pouvait ne voir que ce qui le concerne et gagner du temps en n’ayant pas de tri à faire.
  4. Ordonner les pages et leur donner des statuts Quand le client peut voir ce qu’il a à valider en un coup d’œil, il gagne en productivité, il ne s’occupe pas de ce qui est in progress, et il ne les ouvre même pas ! La vue sous forme de colonnes permettait d’avoir une overview très claire du travail à faire, de sa quantité.
  5. L’historique des versions Cette feature est vraiment utile pour voir l’évolution et recetter après traitement des tickets, car non, ce n’est pas évident de savoir évaluer si le bloc a bien été réduit comme on l’avait demandé, si on a bien augmenté la taille de la typo ou si le fond gris a bien été renforcé ! En bonus, ça permet d’évaluer clairement quand un projet patine au nombre de versions produites, bref, c’est indispensable.
  6. La validation des artboards en autonomie Pouvoir changer les statuts des pages était vraiment un énorme plus d’Invision, le client effectue lui-même la validation, et ce geste symbolique change le rapport au projet, l’implication est factuelle.

Figma à la traîne

Aucune des features évoquées ci-dessus n’est proposée par Figma : aucune rétention des artboards, aucun statut de page, le système de ticketing manque de puissance et les pages n’ont pas de statut.

Un certain nombre de ces problèmes sont compensables par des plug-ins, mais on rentre dans une utilisation en mode plus expert de cette application, qui doit aussi pouvoir être utilisée en mode vitrine par des clients.

Certains me diront que cela fonctionne en vue prototype, c’est plus ou moins vrai, car les projets ne sont pas systématiquement prototypés, de plus, quand au sein d’un prototype une page est en cours de modification, elle apparaît quand même.

Et puis parfois, on ne maquettera pas tout un parcours, mais simplement des écrans clés, il n’est pas rare de ne maquetter que le nécessaire et que le reste soit vu directement en intégration…

A l’usage on peut clairement établir que Figma ne remplit pas le job qu’Invision remplissait, et qu’aucun équivalent n’existe à ce jour.

Comment faire valider des livrables ?

A la recherche de l’outil de mise à disposition des maquettes idéal

On a tout testé : Marvel, Zeplin et consorts… et on a même eu un faux espoir quand Invision s’est targué d’être compatible avec Figma, et nous avons été très déçus.

Si Zeplin offre une ébauche de process acceptable, son prix est trop élevé pour une solution clairement dégradée.

Marvel se positionne davantage comme un outil de prototypage et ne remplit pas cette mission de vitrine correctement.

Quant à Invision, quelle déception, on peut simplement voir les maquettes dedans, mais on ne peut en aucun cas reproduire un workflow efficace.

Concrètement, on peut en déduire qu’aucun outil ne peut à ce jour remplacer Invision, et que nous allons devoir trouver des biais pour mettre en place un process qui soit suffisamment clair pour nous comme nos clients.

Organiser les pages du projet avec des statuts

Dans un premier temps, on a décidé de mettre en place une bonne organisation des pages du projet, afin de le découper au maximum.

Ainsi, chaque lot de page cohérent correspond à une page, et nous avons mis à part les éléments suivants : les pages archivées et la partie styleguide, que nous construisons au fur et à mesure.

Nous avons aussi mis en place un système de reconnaissance de statuts des lots de page avec des emoji.

Visuel_statuts-des-pages-dans-figma

 

Le code couleur est simple :

  • Les lots de pages dont le contenu est indiqué avec une pastille verte ont été validés
  • les pastilles bleu jaune indiquent les lots de pages contenant des éléments à review
  • les pastilles rouges indiquent les éléments en cours de correction et à ne pas consulter
  • les pages sans pastilles ne sont pas à revoir / à consulter (non démarrées ou en cours de construction)

Pour ajouter des pastilles, on fonctionne de manière très artisanale puisque nous utilisons des emoji que nous copions-collons, et c’est parfois un peu fastidieux. Par ailleurs, ces statuts ne permettent pas d’automatiser un envoi de mail à un client pour lui demander d’aller review des pages par exemple, c’est donc une “rustine” qui permet malgré tout de s’y retrouver, notamment au sein des gros projets.

Ajouter des status de pages

Plusieurs plugins Figma permettent de mettre des statuts sur les artboards, après en avoir essayé plusieurs, plus ou moins complexes, nous avons de notre côté choisi un plugin extrêmement simple : Is it done yet ?

Simple d’utilisation, en un simple clic droit, on peut ajouter des status d’artboards identiques à ceux que nous avons mis sur les Pages.

 

status-artboards

Ici encore c’est une méthode très artisanale puisque nous n’avons aucun moyen d’automatiser l’envoi d’un statut à un client, on doit donc se fendre d’un mail ou d’un message Slack pour l’en avertir.

Utiliser le prototype pour ne partager que certaines pages

On peut également utiliser l’outil prototype pour ne mettre à disposition que certaines parties du projet.

Cette feature peut être intéressante pour échanger avec des personnes plus éloignées du projet, comme des responsables hiérarchiques du côté du client, mais nous ne la trouvons de notre côté pas efficient quand il s’agit d’échanger au quotidien avec l’équipe Produit ou l’équipe de Technique, qui a priori saura avoir une utilisation en mode expert.

Et la validation dans tout ça ?

Et bien là encore c’est à l’ancienne, terminé la validation directe par le client, il doit apposer un commentaire et on doit mettre à jour le statut de la page à la mains. C’est un vrai retour en arrière pour nous, et on perd la symbolique de la validation en autonomie.

Quelles leçons en tirer ?

On reste malgré tout insatisfaits du process de travail offert par Figma, c’est vraiment le gros point faible de l’outil. Nous avons finalement pris le parti de capitaliser sur l’outil de commentaire natif bien qu’il soit largement améliorable.

Si Figma est un outil qui nous permet de gagner pas mal de temps sur la phase de design, on reste sur notre faim, mais nous ne sommes sûrement pas les seuls à être gênés par l’expérience offerte sur le travail en externe. On attend patiemment que Figma recueille la parole de ses utilisateurs et fasse évoluer son outil ou l’ouvre davantage sur des applications tierces… Et on peste parce que la gestion de projet est plus fastidieuse, plus longue et offre un certain inconfort à nos clients.