Critique des outils de design d’interface & recommandations pour le futur

févr. 09, 2020

Introduction

J’aime savoir pourquoi les choses sont telles qu’elles sont quand je ne suis pas à l’aise avec. Cela permet d'identifier des problèmes qui sont causés par de mauvais choix initiaux et de réfléchir à une solution pour les résoudre. Cela fait deux ans que je travaille dans une entreprise en étroite collaboration avec des designers et des développeurs. Ce qui m'a toujours frappé, c'est la différence qu'il peut y avoir entre ce qui était prévu sur les maquettes des designers et le résultat final après intégration. C'est aussi à quel point la communication entre les designers et les développeurs est compliquée et que les outils et mode de pensée utilisé par chacun n'aide pas à améliorer cela.

Je suis moi-même développeur et un peu designer, j'aime autant les deux disciplines car elles sont complémentaires. J'ai toujours trouvé étrange que dans beaucoup d’entreprises, les développeurs et les designers soient dans des équipes séparées et travaillent chacun de leur côté. Récemment, je me suis aussi posé la question, pourquoi les designers utilisent les mêmes outils et les mêmes méthodes pour fabriquer des applications, comme des sites internet à vocation marketing ? Toutes ces questions m'ont mis un doute sur la pertinence de l'état actuel des outils de design et j'ai voulu comprendre pourquoi ces outils sont tels qu'ils sont aujourd'hui.

Un peu d’Histoire

Le design d'interfaces n'est pas une discipline récente, la première interface graphique moderne est apparu au sein du Xerox lab dans les années 70. Cette interface graphique était celle d'un système d’exploitation. Pendant longtemps, le design d'interfaces a été pris en
charge par les concepteurs d’OS. Ce sont eux qui définissent, encore aujourd'hui, l'apparence des boutons, fenêtres, onglets, et de tout les composants d’interface de leur plateforme, et les outils utilisés pour décrire une interface graphique sous forme de code. Ce qui laisse aux développeurs l'unique responsabilité de bien utiliser ses frameworks selon la documentation que les éditeurs d’OS mettent à leur disposition.

Quand le Word Wide Web est proposé en 1989 par Tim Berners-Lee, ce logiciel est destiné à faciliter le partage et l’indexation de documents entre les ordinateurs de plusieurs universités et centres de recherche. Le langage conçu pour écrire ces documents est l’HTML (Hyper Text
Markup Language). C’est un langage de description sémantique du contenu d'un document et non un langage d'interfaces graphiques.

Durant toute la décennie de 2000 à 2010, le web est utilisé pour publier des sites Internet de communication marketing qui nécessite d'être conforme à la charte graphique de la marque de l'entreprise qui l'édite. Le web designer est chargé de dessiner le site internet conformément à cette exigence, grâce à ses compétences, plus proche des designer graphique produisant des documents imprimés, que des designers d'interfaces concevant des interfaces graphiques d’applications natives à l’époque.

Si nous résumons grossièrement la situation, jusqu’en 2010, les gens utilisent le web à peu près comme ils utilisaient l’impression et les logiciels sont conçus avec les technologies fournis par les éditeurs de système d’exploitation sur des ordinateurs portable ou fixes.

Mais depuis 2010, le web attire de plus en plus l'attention des éditeurs de logiciels, et la raison est simple : le Web est une plate-forme qui a cette époque est assez mature technologiquement pour permettre le développement de véritable logiciel. C’est une plateforme qui a l’avantage d’être populaire et accessible à partir de n'importe quel appareil, indépendamment de ces spécifications techniques.

Les entreprises se mettent donc à incorporer des professionnels qui travaillent depuis longtemps avec le web, dans leurs équipes de design d’interfaces. En arrivant dans ces équipes, ces designers web apportent leurs outils, comme sketch, Photoshop ou Illustrator et
leurs méthodes de travail. De plus en plus, ces équipes vont concevoir des interface graphique d’applications complexes de la même manière que les web designers faisaient des sites web. Et le terrain est favorable ! Avec le web, on ne part de rien, il n’y a aucun thème par défaut, aucun composant d’interface de base (sauf les boutons et les éléments de formulaires mais leur apparence n’est pas cohérente avec le reste des styles par défauts). Les designers ont donc une liberté complète sur la définition fonctionnelle des composants et leur apparence. De plus le design d’interfaces d’applications natives se limitait au mieux à la réalisation de wireframe préalablement à l’intégration, au pire on fabriquais les interface à la volé et c’étais les développeurs qui étais chargé de l’UI design avec des outils comme QT Design Tools qui est le logiciel de création d’interface du framework QT.

Pourquoi nos outils ne sont plus adaptés ?

Le problème des images statiques

La plupart des logiciels de design exportent les maquettes sous forme d’image (svg, pdf, png ou jpg) et c’est assez problématique parce qu’on ne peut pas interagir avec des images. Bien sûr, les outils de prototypage permettent aux designers de définir des zone cliquable, des transition entre les pages voir même des micro-interactions simples au sein d’un même écran, mais plus le temps passe plus les interactions rendus possible par les navigateurs sont complexes et variées, et le prototypage à base d’images ne pourra pas suivre la cadence bien
longtemps.

La représentation sous forme d’image d’une interface graphique n’est plus adaptée pour communiquer précisément les intentions du designer. Et tant que les designers continuent
d’utiliser des images pour communiquer leur travail, celui-ci sera toujours prompt à de mauvaises interprétations de la part des développeurs.

J’ai cherché à lister quelques-une des interactions qu’il est impossible de communiquer par
des images statiques :

  • Le survol d’un élément
  • Le focus
  • Le scroll
  • La navigation par onglet
  • L’ouverture d’un menu

Quelques-unes de ces interactions peuvent quand même être reproduite dans des logiciels de prototypage, mais à quoi bon passer des semaines entières à produire des maquettes réaliste qui finirons archivée dans un coin de son ordinateur quand on pourrait utiliser ce temps pour manipuler directement le design du vrai produit.

Le problème du mode de positionnement absolue

Il y a 10 à 15 ans, la seule manière de positionner des éléments sur le web était de faire des tableaux et de jouer avec la propriété vertical-align. Maintenant nous avons les conteneurs flexibles et les grilles CSS. Et tous les sites internet sont construits en utilisant ces systèmes de mise en page. Malgré cela, les outils de design ont choisi d’ignorer ces trois systèmes et d’opter pour un mode de positionnement absolu des éléments dans le canevas. Cela rend la réalisation de maquettes responsive difficile, car il faut réorganiser à la main les éléments
affichés pour chaque taille d’écrans.

Pour tenter de palier à ce problème, Figma et sketch intègrent un système de mise en page basé sur des contraintes, et depuis récemment Figma propose même AutoLayout qui ressemble fortement au mode de positionnement flexible de CSS. Malgré cela, ces systèmes ajoutent inutilement de la complexité et augmentent la difficulté de l’apprentissage pour les designers qui préféreront le positionnement absolue par défaut de ces logiciels. Et puis à quoi bon utiliser énormément de temps pour réaliser une maquette parfaite quand ce livrable est destiné à la poubelle une fois l’intégration terminée.

Arrêtons-nous sur les différences fondamentales entre un moteur de rendu vectoriel et un moteur de rendu html.

Dans le paradigme vectoriel, tous les éléments qui sont affichés à l'écran ont des coordonnées exprimée de manière absolue par rapport au coin supérieur gauche du canevas. Leur taille aussi est exprimée de manière absolue souvent en pixels. Aucune décision quant à la position ou à la taille des éléments n'est laissée au moteur de rendu tout est décris explicitement. C'est tout à fait différent dans le paradigme HTML, ici la taille d'un élément varie en fonction de la taille des enfants de cet élément. Par exemple la taille d'un bouton et déterminée en fonction de la longueur du texte de son label. De même que la position de ces éléments est déterminée par rapport à la taille et à la position des éléments frères. Le CSS et les modes de mises en page sont là pour modifier le comportement par défaut du moteur de rendu, mais le principe de base reste le même : l’intégrateur définit le contenu et le moteur de rendu se charge de l’afficher de la bonne manière. Tout cela est rendue possible, car le DOM est l'objet qui décrit la structure d’un document HTML, il permet d'établir des liens hiérarchiques entre les différents éléments de la page. C'est cet objet qui va aider le moteur de rendu à déterminer la taille et le positionnement des éléments du document est à transformer le tout en images en fonction des propriétés de chaque élément et de ses relations hiérarchiques avec ses enfants ou sont parent.

Sachant cela, on peut affirmer que les développeurs de logiciels de design ne font que tenter de ressembler au Web alors qu'ils ont des moteurs de rendu tous prêts et très performant à leur disposition.

Le problème d’avoir un outil pour tout faire

La tendance actuelle est de normaliser les étapes de design afin de mieux intégrer les équipes de design dans le processus de réalisation d’un logiciel et de faciliter la communication entre les designers et les développeurs. C'est pour faire cela qu'est apparu le principe du design system. Il s’agit de construire un référentiel de normes, bonnes pratiques et de styles commun aux designers et aux développeurs. Cette solution permet de faciliter la communication entre les équipes et de réduire la dette design et la dette technique du front-
end.

Dans tout bon design system, on peut distinguer plusieurs couches de complexité :

Les design tokens

Dedans on trouve la palette de couleurs, l’échelle typographique, les valeurs de border radius, les polices de caractères utilisée et tout les autres style qui forment votre identité de marque.

Une librairie d’assets

C’est l’ensembles des icônes, des illustrations ou des images qui seront utilisés dans les maquettes

Une librairie de composants,

On pourrai définir un composant comme un assemblage de design tokens et d’assets. Dedans on peut y trouver les boutons, les éléments de formulaires, etc...

Des modules d'interfaces et des écrans

Qu’on pourrai définir comme étant un assemblage de composants, d’assets et de données qui forme l’interface complète de l’application.
Dans une plus ou moins grande mesure chaque étape cité ci-dessus peut être réalisé dans les logiciels de design d’aujourd’hui. Le problème, c'est que toutes les fonctionnalités qui permettent de réaliser ces étapes sont toutes concentrées sur un écran et parfois cachées dans des menus. Pourtant, quand on doit choisir les couleurs de la palette ou les styles de textes, nous n'avons pas besoin de voir le canevas et les outils de tracé vectoriel puisque ces derniers ne sont pas utiles à ce moment-là. De même, dessiner des pictogrammes requière
uniquement un éditeur vectoriel qui exporte au format svg, pas besoin alors, d’afficher les outils de prototypage. Nos outils devraient naturellement encourager les designers à faire de bons produits en les aidant à faire des choix éclairé et en restreignant les fonctionnalités
disponibles à certaines étapes spécifiques pour éviter d'ajouter de l’inconsistance au design. Il ne devrait pas être réalisable de modifier la couleur de texte ou la valeur du border-radius sur l’instance d’un composant à l'étape de conception des écrans. De même, il devrait y avoir des alertes quand la couleur de texte choisi ne permettra pas à une certaine portion de la population de la lire correctement.
En plus de nuire à la communication entre les développeurs et designers, ces outils nuisent aussi à la créativité, de par leur fonctionnement très différent de celui d'un navigateur Web.
Ils ne donnent pas aux designers une vision précise de ce qu'ils peuvent ou ne peuvent pas designer. N’oublions pas que

Parce que la forme est contraignante, l'idée jaillit plus intense !
— Charles Baudelaire

Conclusion

Je pense que le problème le plus important des outils de design est qu’ils éloignent les designers du produit final. Ils n'ont aucun contrôle direct sur l'interface du produit. Ils doivent systématiquement passer par les équipes de développement pour modifier la moindre valeur CSS. Aujourd'hui, il existe des outils comme WebFlow, qui donnent aux
designers la capacité de créer de A à Z un site Internet à partir d'une interface graphique qui ressemble fortement aux outils de design qu'ils ont l'habitude de manipuler. Il devient alors possible d'imaginer un logiciel de design qui permet de manipuler directement le design des
composants écrit avec le framework choisi par l'équipe de développement.

De nombreux outils tentant de résoudre les problèmes exposés ici sont en cours de conception, comme par exemple Modulz, dont le slogan est « concevez, développez, documentez et déployez votre design system — sans écrire de code. ». Le principe de Modulz et simple, ce logiciel propose une librairie de composants sous la forme de fichiers reactjs, directement modifiable grâce a un logiciel fait pour les designers, ainsi qu'un outil qui permet d'écrire la documentation de chaque composant de la rendre accessible en ligne à vu de toutes les équipes d'une entreprise. Cela intègre mieux les designers au processus de production et permet de maintenir sur le long terme un design système sans avoir deux versions distinctes qui doivent rester synchrone.
Il faut que les designers en finissent avec les images statiques et le positionnement absolu pour se rapprocher du produit final. Il faut aussi répandre l'usage du design system, que le mode de pensée des designers soit plus proche de celui des développeurs afin de réduire le
faussé qui se creuse entre les deux disciplines.

Bibliographie

Rémi Caillot

Je suis étudiant à Gobelins, l'école de l'image en alternance chez Mindsay. Ce blog me sert à parler de mes projets et publier des articles / podcasts