Les outils de conception manquent de piste. Voici comment nous pouvons les corriger.

Il se passe rarement une journée où je ne passe pas au moins un peu de temps à penser aux outils de conception. Il y a quelques années, j'ai construit un outil de conception acquis par Marvel. C'était il y a plus de deux ans, mais depuis lors, le paysage n'a pas beaucoup changé, et ma passion pour l'améliorer n'a pas changé non plus.

Récemment, j'ai tweeté sur les outils de conception - une chose qui se produit de temps en temps.

Je n'étais pas le seul à dire ce que j'avais à penser ce jour-là, d'autres ont aussi sonné.

Le 28 juillet 2017 n'était pas un bon jour pour les outils de conception.

Il y a beaucoup de bonnes informations enfouies dans ces fils Twitter, mais depuis longtemps, je voulais prendre le temps de plonger profondément dans ce que je pense qui est si fondamentalement brisé sur le modèle actuel d'outil de conception, ainsi comme un indice de la direction, je pense que nous devrions nous diriger.

Nous ne faisons que dessiner des images. C'est fou.

Presque tous les outils de conception populaires sont exportés vers des images. Ceci est problématique pour plusieurs raisons:

  1. Vous ne pouvez pas interagir avec une image. Les outils de prototypage nous permettent d'ajouter des transitions d'écran et des interactions simples aux images. Cependant, comme nos produits continuent d'exiger des transitions d'écran et des micro-interactions plus avancées, les images ne peuvent tout simplement pas suivre.
  2. Les images ne sont pas fluides. Communiquer des décisions de conception réactives à travers des images est généralement une tâche difficile.
  3. Les images ne sont pas avec état. Afin de communiquer efficacement les différents états d'une interface utilisateur, de nombreuses images sont souvent nécessaires.
  4. Les images bitmap dépendent de la résolution. Avec l'avènement des dispositifs rétiniens, les images peuvent parfois être mal rendues.
  5. Les fichiers images ont tendance à être lourds et sont souvent lourds à stocker, à gérer ou à partager.

Tant que les outils de conception continueront d'exporter des images, ils ne pourront jamais produire des représentations précises de nos produits. Ce manque de précision entrave la communication entre les concepteurs et les développeurs. Tant que les concepteurs continueront d'utiliser un support terriblement inadéquat pour communiquer leur travail, ce travail sera toujours sujet à une mauvaise interprétation.

C'est un point très important car, à la base, presque tous les outils de conception convertissent des formes vectorielles en images. Photoshop, Illustrator, Marvel, Adobe XD, Sketch et Figma sont tous les mêmes à cet égard. Pourtant, les images ne peuvent communiquer que partiellement l'intention de conception. À mesure que nos produits continuent d'adopter et de prendre en charge des interactions complexes, l'entrée vocale, l'entrée vidéo, la réalité augmentée, la réalité virtuelle, la sensibilité à la température, etc., la valeur de ces outils diminuera rapidement. La conception basée sur l'image est une impasse.

Nos outils de conception doivent manipuler le produit réel, pas une image de celui-ci.

Nos produits sont interactifs. Nos outils sont statiques.

J'ai abordé cela dans mon point précédent, mais c'est super critique, alors j'ai pensé que j'élaborerais un peu.

Pensez à la quantité d'interactions simples qui sont courantes dans presque tous nos produits mais qui ne peuvent pas être communiquées via nos outils de conception. Voici une brève liste du haut de ma tête:

  • Survoler un bouton
  • Concentrer une entrée
  • Cocher une case
  • Contenu tabulé
  • Zones de défilement
  • Index de tabulation pour les états focalisés
  • Raccourcis clavier

Bien sûr, certaines de ces fonctionnalités peuvent être imitées avec une ingénierie hacky mais il faut se demander, quel est le point sur Terre? Pourquoi les concepteurs ne peuvent-ils pas simplement concevoir le produit réel?! En fin de compte, toutes les maquettes sont jetables, mais les concepteurs passent des mois à les peaufiner à la perfection. Ce temps serait beaucoup mieux utilisé pour peaufiner le produit réel.

Je n'irai pas trop loin dans le trou du lapin «si les concepteurs doivent coder» mais je ne suggère pas que nous écrivions tous du code. Je dis simplement qu'il n'y a aucune bonne raison pour laquelle nos outils de conception ne peuvent pas prendre en charge la manipulation directe de nos produits en direct.

Framer fait un meilleur travail que la plupart dans ce département, en soutenant des interactions avancées et détaillées. Le reste du peloton est très loin derrière.

Nos outils doivent prendre en charge le paradigme de mise en page du Web

Jusqu'à il y a environ un an, la seule façon de créer des mises en page sur le Web était d'utiliser les propriétés CSS display: table et vertical-align. Maintenant, nous avons Flexbox et bientôt nous aurons une grille CSS. Ces trois moteurs de mise en page fonctionnent de manière assez similaire, en utilisant le flux du DOM. Presque tous les sites Web sont construits à l'aide de l'un de ces trois systèmes de mise en page.

Il est donc logique que nos outils de conception prennent en charge le même modèle de disposition. Droite?

Eh bien, presque tous les outils de conception ignorent ces systèmes de mise en page, optant plutôt pour positionner chaque couche absolument dans son plan de travail. Cela ouvre un gouffre entre le fonctionnement du Web et le fonctionnement de nos outils de conception, introduisant de nombreux problèmes:

  • La conception réactive devient très difficile car chaque couche doit être réorganisée manuellement pour chaque point d'arrêt. Alternativement, un système de mise en page basé sur des contraintes peut être introduit mais qui ajoute de la complexité, accentue les courbes d'apprentissage et empêche finalement les développeurs de transférer la mise en page directement sur le Web.
  • Étant donné que chaque couche est en dehors du flux du document, la manipulation du contenu devient délicate. Par exemple, si vous souhaitez ajouter un élément à une liste, vous devez repositionner manuellement les autres éléments de cette liste. Bien sûr, des fonctions de répétition et d'autres fonctionnalités sophistiquées peuvent être introduites pour soulager la douleur, mais encore une fois, cela introduit une complexité supplémentaire et complique quelque chose que le DOM nous donne gratuitement.
  • Le positionnement absolu conduit naturellement à des coordonnées et des dimensions de pixels fixes. Cela engendre l'inflexibilité et, encore une fois, est un énorme écart par rapport au fonctionnement du Web. Le Web est construit sur des unités fluides comme em, rem, vh, vw et%. Nos outils devraient prendre en charge ces unités par défaut.

Les outils de conception ne devraient pas avoir besoin de ressembler ou de refléter le Web et ses nuances - ils devraient simplement ÊTRE le Web.

Un outil monolithique n'est pas le chemin

Une bonne conception se produit par étapes. Un système de conception bien structuré comporte plusieurs couches distinctes:

  1. Palette de styles Une collection de couleurs, d'ombres, d'espacement, de rayons de bordure, de polices de caractères, de tailles de police, d'animations et d'autres styles qui forment l'identité de votre marque. Actuellement, la plupart des outils de conception ne prennent en charge que les palettes de couleurs. Jusqu'à ce qu'ils prennent en charge les autres propriétés de style, il sera extrêmement laborieux de concevoir systématiquement.
  2. Actifs Cela comprend des éléments tels que des icônes, des illustrations et des images. Il existe des éditeurs d'image phénoménaux et l'outil vectoriel de Figma est excellent mais en ce qui concerne le support SVG, nos outils de conception laissent beaucoup à désirer.
  3. Bibliothèque de composants Un composant est une collection de styles et de ressources qui rend les données en un seul élément dans une variété de variantes. Les exemples incluent les boutons, les entrées, les badges, etc. Comme je l'ai mentionné, Figma et Sketch ont récemment résumé ce processus loin du flux de dessin principal - c'est dommage qu'ils ne soient que des images de composants et non de composants réels.
  4. Modules Un module / composition est une collection de composants qui restitue les données à une partie de l'interface utilisateur encapsulée dans une variété d'états. Les exemples peuvent inclure des barres d'en-tête, des menus d'onglets, des formulaires de connexion, des tableaux, etc. Comme les modules ne sont que des composants complexes, je suppose que Figma et Sketch peuvent également les gérer. Bien qu'il puisse être utile de séparer les deux.
  5. Écrans Un écran est une collection de modules, de composants et de données pour former une interface utilisateur complète avec laquelle l'utilisateur peut interagir.

La plupart des outils de conception fournissent des fonctionnalités qui prennent en charge chacune de ces étapes de conception dans une certaine mesure au moins. Le problème est que toutes les étapes sont confondues. Presque tous les outils de conception n'offrent qu'un seul mode: le mode dessin. Vous créez un ensemble de plans de travail et commencez simplement à dessiner des images. Ce n'est que très récemment que des outils tels que Sketch et Figma ont résumé des composants / symboles éloignés du mode de dessin principal - ce qui est étrange car dans le développement frontal, les composants ont été abstraits pendant de nombreuses années.

Lors de la conception d'une palette de styles, je n'ai pas besoin de voir les plans de travail ou les outils vectoriels. Je veux voir des outils pour choisir des couleurs harmonieuses. Je veux des préréglages pour des choses comme une échelle d'espacement de 8dp ou une sélection d'échelles de type.

La conception d'une icône nécessite un mode de pensée complètement différent de la conception d'un flux utilisateur. Un éditeur SVG simple qui m'a permis de dessiner des rectangles, cercles, lignes et chemins SVG natifs, puis du code SVG optimisé exporté serait idéal.

Lors de la conception d'un composant, je ne devrais plus penser à des styles individuels - je devrais simplement choisir des styles dans ma palette de styles prédéfinie. Je ne peux pas simplement commencer à peaufiner les styles pour un composant, car cela introduirait une incohérence, diluant l'efficacité de mon système de conception. Une fois qu'une palette de styles est en place, elle ne doit être modifiable qu'à la source.

De même, lors de la composition d'un module, je ne devrais être exposé qu'à ma bibliothèque de composants prédéfinie. Il ne doit pas y avoir de propriétés de style dans une barre latérale. Pas d'outils vectoriels. Juste une bibliothèque de composants réutilisables que je peux glisser-déposer pour composer des modules.

Il en va de même pour la composition d'écrans. À ce stade, nous ne faisons que réutiliser des composants et des modules pour créer une interface utilisateur. Nous ne pensons pas aux styles ou aux formes ou à d'autres efforts créatifs. Nous nous concentrons principalement sur la conception du contenu et des flux d'utilisateurs.

Chacune de ces étapes de conception pourrait avoir lieu dans des outils distincts entièrement ou simplement dans des modes différents au sein du même outil. Je ne pense pas que cela compte beaucoup. Une chose est sûre cependant, la plupart des outils de conception actuels ne parviennent même pas à reconnaître le processus.

Nos outils devraient favoriser une bonne conception

Les designers ont le luxe rare de pouvoir ajouter un nombre infini de styles uniques à un projet sans aucune répercussion notable. Besoin d'une taille de police légèrement plus grande? Il suffit de le cogner. Pas de biggie. Besoin d'une couleur légèrement plus lumineuse? Il suffit de le modifier. C'est cool. Vous pourriez même créer plusieurs plans de travail dans le même projet, chacun utilisant des valeurs légèrement différentes pour des styles similaires et cela passerait probablement inaperçu.

Votre outil de conception ne vous dira jamais que vous ne pouvez pas faire quelque chose. Cela ne vous incitera jamais à utiliser une couleur hors marque. Cela ne vous empêchera jamais d'utiliser une valeur d'espace blanc qui n'appartient pas à votre échelle d'espacement. Cela ne vous avertira jamais que 20% de la population ne peut littéralement pas voir le texte gris clair que vous venez de concevoir.

Et pourquoi pas…? Parce que les outils de conception s'en moquent.

Les outils de conception sont tellement égarés par une vision de créativité illimitée qu'ils ont perdu de vue ce que signifie concevoir judicieusement, concevoir de manière inclusive, concevoir systématiquement.

En termes simples, les outils de conception nous permettent de faire tout ce que nous voulons. Dans une certaine mesure, ce niveau de créativité sans limites est utile, en particulier dans les phases d'idéation. En tant que concepteurs d'interface utilisateur, la majorité de notre flux de travail ne nécessite pas beaucoup de créativité. Au contraire, notre flux de travail nécessite la réutilisation, la répétition, la familiarité et la standardisation; besoins que nos outils font peu pour satisfaire.

Cette liberté illimitée est en contradiction avec la réalité du développement web. Étant donné que les développeurs travaillent avec le produit réel, ils doivent tous travailler avec le même code. Les développeurs ne peuvent pas simplement ajouter des tailles de police isolées ou des valeurs de couleur aléatoires à la base de code. Premièrement, un linter (un message d'alerte avertissant d'un code mal écrit) commencerait probablement à crier immédiatement. Sinon, leur savoir-faire de mauvaise qualité serait probablement appréhendé lors d'une révision du code. S'il réussissait à se faufiler entre les mailles du filet, un impact notable sur les performances finirait par sonner l'alarme.

L'un des problèmes les plus perturbateurs que je vois sur les équipes de produits est la déconnexion entre les équipes de conception et de développement. Les développeurs travaillent avec des directives et des contraintes strictes depuis des années. À moins que nos outils de conception n'adoptent ces mêmes contraintes, l'écart ne se réduira jamais.

Nous devrions concevoir avec des données en direct

Les données en direct ont été intégrées dans une certaine mesure par de nombreux outils, ce qui est formidable à voir. Adobe XD a des fonctionnalités vraiment intéressantes pour générer de fausses données qui ressemblent à des données en direct typiques. Invision Craft fournit également des fonctionnalités de données en direct intéressantes pour Sketch.

Les données en direct ne doivent cependant pas s'arrêter au texte. D'autres éléments comme les images et la vidéo peuvent avoir un impact énorme sur l'expérience utilisateur en augmentant considérablement les temps de chargement. Si vous travaillez sur le Web, les outils de développement du navigateur vous permettent de limiter la connexion pour ressembler à une variété de vitesses Internet. Ensuite, vous pouvez voir de première main comment un nouveau contenu peut affecter l'expérience utilisateur.

Nos outils de conception nous offrent-ils ces luxes?

En un mot: non.

Plus nous nous rapprochons de la conception du produit réel, plus notre travail de conception peut être utile et impactant.

Le web est ouvert. Nos outils devraient l'être aussi.

L'une des choses vraiment belles sur le Web est son accessibilité ouverte. Un site Web peut être consulté dans n'importe quel navigateur Web sur à peu près n'importe quel appareil.

Comment cela se compare-t-il aux outils de conception? Eh bien, il y a quelques jours, mon frère David m'a demandé un examen de la conception d'une application qu'il construit. Il m'a envoyé un fichier Sketch. Quand je l'ai ouvert, c'est arrivé…

La plupart des outils de conception sont des jardins clos. Si un collègue travaille dans Photoshop, un autre collègue ne peut pas ouvrir ce projet dans Sketch. Il ne suffit même pas que toute votre équipe utilise le même outil - elle doit également utiliser la même version de cet outil.

Marvel et Figma font du bon travail ici, offrant des plans gratuits et des fonctionnalités de collaboration innovantes.

Alors, quel est l'avenir des outils de conception?

L'innovation dans l'outillage de conception est extrêmement précieuse et il y en a eu beaucoup récemment. Chez Airbnb design tools, Jon Gold et Benjamin Wilkins ont travaillé sur React-Sketchapp qui prend les composants React et les rend dans Sketch. Jon et Ben ont également travaillé sur un nouvel outil époustouflant qui prend des croquis de serviette et les transforme en quelque sorte en composants React.

Adam Morse, Brent Jackson et John Otander travaillent sur une suite d'outils chez Compositor qui résout essentiellement tous les problèmes de cet article et peut-être du monde.

Je travaille sur Modulz, un nouvel outil de conception et un système de conception open source qui vise également à résoudre les problèmes que j'ai mentionnés dans cet article. Si vous êtes intéressé, suivez Twitter pour les mises à jour.

Bien que l'innovation dans l'outillage soit importante, le véritable défi est l'éducation. La communauté du design n'est tout simplement pas prête pour un outil de conception systématique. De nombreux concepteurs ont peu ou pas d'intérêt pour les systèmes de construction. Pour certains, le JPG est l'objectif final - le Dribbble aime.

Nous devons en quelque sorte inspirer une culture de responsabilité. Les développeurs ont une culture de responsabilité depuis des années. Ils ont des outils pour contrôler leur code. Si un développeur s'écarte à plusieurs reprises de ses directives de code strictes, vous pouvez être sûr que le problème sera résolu.

Pendant ce temps, les concepteurs amassent fréquemment des montagnes de couches dans un désarroi complet, sans tenir compte de la dénomination, du regroupement et de l'ordre des couches. C'est beaucoup à chacun. Étant donné que la sortie (image raster) n'est pas affectée par l'entrée (couches vectorielles), il n'y a pas vraiment de charge à organiser pour les concepteurs. Les concepteurs excusent souvent ce manque d'organisation en romantisant l'art du design, se présentant comme des magiciens qui doivent être livrés à eux-mêmes pour pouvoir jouer.

Nous devons également inspirer une culture d'inclusion. Nous devons décourager activement les erreurs professionnelles comme les couleurs de texte ultra légères qui rendent le texte difficile à lire pour de nombreuses personnes, ou les polices de caractères de très haute qualité qui ralentissent le chargement des pages Web, ou les éléments d'interface utilisateur sans motif qui rendent les choses difficiles à comprendre pour les personnes daltoniennes. Actuellement, ce type de faute professionnelle est applaudi dans la communauté du design. Si nous voulons accueillir un outil de conception intelligent, nous devons inverser cette culture.

Si un outil de conception systématique doit gagner nos cœurs, il doit d'abord éduquer.