|
|
Avant de commencer, il faut se rendre compte d’une chose : qu’on fasse du sur-mesure ou pas, 60 à 80% de nos interfaces sont “industrialisables”. Grilles, typographies, espacements… il n’y a pas une interface qu’on ne puisse rationaliser. En fait, on fait déjà tous de l’industrialisation Design. Sans le savoir, ou sans le vouloir.
La seconde chose, c’est qu’il faut garder à l’esprit que la création d’une interface n’est pas un travail de Design uniquement. Le Design répond et illustre une fonctionnalité, qui est ensuite exécutée techniquement. Une interface est donc le résultat d’un travail collaboratif entre plusieurs métiers.
|
Les interfaces performantes sont le résultats d’opérateurs métier qui communiquent, qui se comprennent les uns les autres, et qui adoptent des méthodes et pratiques communes.
|
Les Designers doivent apprendre à parler et à penser tech, à comprendre les grands concepts pour se les ré-approprier et les intégrer à leur travail. Et c’est la même chose pour les techs qui doivent intégrer les concepts et méthodes Design à leur pratique, pour la faire évoluer.
Dans cette optique, la rationnalisation de nos UIs répond aux besoins suivants :
- Le besoin de mettre en place des standards communs entre les métiers (nomenclature, concepts)
- Le besoin d’un système qui permet de rendre les métiers plus autonomes, plutôt que de les siloter (comprendre le cheminement de construction des interfaces)
- Le besoin d’une meilleure identification du territoire sur-mesure d’une réalisation (avec un territoire mieux défini, le sur-mesure s’exprime plus efficacement)
- Le besoin de maîtriser les coûts design & technique des interfaces, que ce soit en production ou en maintenance
|
Je précise que ces astuces sont génériques. Elles sont donc applicables quelque soit le sujet sur lequel on travaille : un SAAS, un produit, une app, un site WordPress (avec ou sans Gutenberg), un e-commerce, etc.
|
Principe 1 : une conception commune
|
La première étape, c’est d’aligner les métiers sur un mode de conception commun. Pour que chacun puisse comprendre le cheminement de pensée et de construction d’une interface.
Ça signifie :
- Penser ses Designs avec une vision commune (tokens, composants, vues/contextes)
- Penser ses Designs en “mode variable” :
- Des sets de variables pour la construction des interfaces, applicables à plusieurs sujets (plusieurs nomenclatures de tailles, applicables à des espacements, des tailles de font, etc.)
- Le test des interfaces avec des données variables (textes plus ou moins longs, en FR/DE ou autre…)
- Penser ses Designs comme des systèmes compréhensibles et reproductibles :
- ”je comprends comment on crée des nuanciers de couleur, et comment on les utilise”
- “je dois réaliser un écran dont je n’ai pas le Design, je comprends le système et je peux proposer une première version de qualité”
- “j’arrive dans l’équipe : je comprend facilement la manière dont les choses sont conçues et je peux devenir opérationnel rapidement”
- etc.
Une fois qu’on est tous d’accord sur le mode de conception d’une interface, on peut commencer à se créer un ensemble fini d’outils, dont la définition et l’usage trouvent leur traduction en langage graphique ET en langage technique.
|
Principe 2 : espacements et propriétés liées
|
Pas la peine de se complexifier la vie avec des espacements gérés à coup de pelles sur une interface. Ça n’a rien de sur-mesure, ça n’a pas de valeur, c’est horrible à intégrer et vraiment chiant à maintenir.
Optez donc pour :
- Un nombre fini de variables de “spacers” : XS, S, Default, M, L, XL, XXL Utilisables pour tous les margins et paddings de votre interface.
- Ces spacers sont pensés en mode “fixe” (variables en PX ou EM, quelque soit le device) ou “fluide” (espacements pensés en responsive, définis en CLAMP).
- Vous pouvez ensuite utiliser certaines de ces valeurs pour définir différents niveaux de border-radius par exemple (S, Default, M).
→ Mon post complet sur le sujet
|
Principe 3 : typographies
|
En ce qui concerne la typographie, on cherchera l’équilibre entre “faire quelque chose d’intéressant” et “faire quelque chose de compréhensible”. Pas la peine de se prendre pour l’inventeur de la typo, quelques principes suffisent à un travail efficace :
- Un nombre fini de variables de font-size : XS, S, Default, M, L, XL, XXL (tiens tiens, la même nomenclature que les spacers…), déjà anticipées avec leur valeur mobile grâce au CLAMP CSS.
- Trois valeurs possibles de line-height (XS, S, Default), à appliquer selon la taille des textes et le dessin des caractères. Personnellement j’utilise le nombre d’or (1.62em pour Defaut, puis 1.38em et 1.19em).
- 2 possibilités de font-family, nommées selon leur usage et non pas selon le nom de la police de caractères.
Ex : font-brand et font-text, plutôt que “Inconsolota” et “Inter”
- On crée ensuite les styles par défaut de nos balises par assemblage : H1 = font-size XXL + font-family “brand” + font-weigt 700
- On a également la possibilité de séparer le style de la sémantique avec ce système (coucou les SEOs). Mais ça, ça viendra plus tard ;)
- Des tailles d’icônes pensées dans des valeurs EM, relatives à la taille du texte qui les accompagne (dans le cas d’un bouton “icône + texte”)
→ Mon post complet sur le sujet
|
|
|
Troisième sujet “simple mais complexe” à gérer sur les interfaces : la couleur. La tendance actuelle tend à mettre en place des éventails automatiques d’une même couleur. Mais soyons sérieux : qui utilise 10 nuances d’un même bleu sur son interface ?
Au lieu de ça, rationalisons avec :
- Maximum 6 variantes d’une même couleur : De la valeur 50 (faux blanc), au 950 (faux noir), en passant par les valeurs 100, 300, 400/500, et 700. Pas plus
- Des couleurs “standards” utilisées (et personnalisées) sur chaque projet : Un nuancier de gris (+ noir/blanc purs) et des couleurs d’état (erreur, succès, info, alerte)
- Une couleur principale de thème, basée sur la couleur de marque principale du projet, et passée à la moulinette de cet outil pour en sortir le nuancier. Nommée avec du sens : “color-brand” plutôt que “color-red”.
- Une couleur de soutien et une couleur de contraste de notre couleur principale. Couleurs issues de la charte projet, ou déterminée grâce à des outils comme Paleton. Nommées avec du sens, encore une fois : “color-brand-alternative” et “color-contrast”.
→ Mon post complet sur le sujet
|
Toutes ces règles simples bénéficient à la cohérence et à la maintenabilité de nos interfaces. Elles apportent du cadre et un sens précis, et permettent d’arbitrer des choix déterminants en terme d’interface.
Enfin, elles permettent une meilleure identification du territoire de la création sur-mesure : pour un impact concentré et décuplé !
|
|
|
Tout ça, je vous l’apprend dans mon bootcamp “Concevoir et Designer avec Gutenberg”
|
Destiné aux Designers et aux couples Design-Tech, ce bootcamp est composé de 8 sessions de 2h30, étalées sur 8 semaines. La première promotion accueillera 8 participant•es.
L’objectif sera de maîtriser la conception d’interfaces avec l’éditeur de blocks de WordPress, mais pas que. Les modes de conceptions qui seront transmis seront applicables à n’importe quelle typologie de projet : “Gutenberg” n’est que la couche “outil” de ce bootcamp, simplement car il est le meilleur éditeur de contenu du marché à ce jour.
Le détail du programme, les modalités et le prix du bootcamp sont accessibles sur la page dédiée. Je reste disponible par réponse de mail en cas de question !
|
|
|
Whodunit, Be Api, BuxumLunic :
en France ou en Suisse, ce bootcamp est déjà recommandé par des agences de références
|
|
|
|
|
|
|
|
|
|
