Qu’est-ce qu’un design system et en avez-vous besoin ?

Le terme appa­raît dans un devis de refonte, dans une offre d’emploi, dans une réunion où per­sonne ne s’arrête pour le défi­nir. Cha­cun croit com­prendre, et les défi­ni­tions divergent : biblio­thèque d’éléments gra­phiques pour l’un, charte gra­phique moder­ni­sée pour l’autre, affaire de déve­lop­peurs pour un troi­sième. Cet article pose ce que recouvre un desi­gn sys­tem, ce qui le dis­tingue d’une charte gra­phique et à par­tir de quand il devient utile.

La charte décrit, le design system fabrique

La charte gra­phique fixe la manière dont une marque doit appa­raître : quelles cou­leurs, quelles typo­gra­phies, quelles ver­sions du logo, dans quelles condi­tions les employer. C’est un docu­ment de règles, écrit à l’intention de quelqu’un qui va pro­duire quelque chose. Le desi­gn sys­tem reprend ce type de déci­sions et en trans­forme une par­tie en élé­ments réuti­li­sables pour construire des inter­faces : là où la charte indique le bleu prin­ci­pal et les typo­gra­phies à employer, le desi­gn sys­tem four­nit le bou­ton déjà construit, avec ses dimen­sions, son texte et ses dif­fé­rents états.

Deux pré­ci­sions comptent, faute de quoi la suite se com­prend de tra­vers. Le desi­gn sys­tem ne rem­place pas la charte gra­phique : il en reprend sou­vent cer­taines déci­sions pour les appli­quer aux inter­faces, sans cou­vrir tout ce qui concerne la marque ou les sup­ports impri­més. Il peut aus­si inté­grer direc­te­ment ses propres fon­da­tions visuelles lorsque celles-ci ne sont pas réunies dans une charte sépa­rée. Il ne se réduit pas non plus à un stock d’éléments déjà pro­duits : il com­prend aus­si des prin­cipes, des règles d’usage et de la docu­men­ta­tion, sans les­quels per­sonne ne sait quoi employer, ni quand, ni com­ment ajou­ter ce qui manque.

Dans le péri­mètre qui nous inté­resse ici, celui des inter­faces numé­riques, son champ est plus étroit que celui d’une charte sur un point, et plus pro­fond sur un autre : il des­cend jusqu’aux élé­ments uti­li­sables pour construire l’interface. Si la dis­tinc­tion entre iden­ti­té de marque, iden­ti­té visuelle et charte gra­phique ne vous est pas fami­lière, c’est par là qu’il vaut mieux com­men­cer : nous la détaillons dans notre article Charte gra­phique et iden­ti­té visuelle : ne pas confondre. Un desi­gn sys­tem se com­prend mal tant que ces trois notions res­tent mélangées.

Ce qu’il y a dedans

Le conte­nu varie selon l’ampleur du pro­jet, mais on peut le rame­ner à trois grands ensembles : les fon­da­tions, les com­po­sants et la docu­men­ta­tion qui encadre leur usage et leur évolution.

Les fondations et les tokens : des décisions transformées en valeurs nommées

Les fon­da­tions ras­semblent les déci­sions de base sur les­quelles l’interface va se construire : cou­leurs, typo­gra­phies, grille, espa­ce­ments ou rayons d’angle. Cer­taines de ces déci­sions peuvent être expri­mées sous forme de tokens.

Un token, que l’on tra­duit par­fois par « jeton de desi­gn », est une déci­sion de concep­tion à laquelle on donne un nom pour pou­voir l’appeler au lieu de la reco­pier. Plu­tôt que d’écrire la valeur d’une cou­leur à qua­rante endroits dif­fé­rents, on la déclare une fois sous un nom comme « cou­leur prin­ci­pale », et les qua­rante endroits s’y réfèrent. Si cette cou­leur évo­lue, il suf­fit de modi­fier sa valeur à un seul endroit.

L’intérêt n’est pas l’élégance de la méthode, c’est ce qu’elle évite. Sans cette logique, une modi­fi­ca­tion glo­bale sup­pose de retrou­ver toutes les occur­rences de la valeur, y com­pris celles que per­sonne n’a docu­men­tées, et d’espérer n’en avoir oublié aucune. Le prin­cipe vaut au-delà des cou­leurs : tailles de texte, graisses, espa­ce­ments, rayons d’angle. C’est la par­tie la plus abs­traite du sys­tème, et celle dont les modi­fi­ca­tions peuvent se pro­pa­ger le plus largement.

Les typo­gra­phies illus­trent tou­te­fois une limite : nom­mer une police ne résout ni son char­ge­ment, ni ses condi­tions de licence, ni les dif­fé­rences d’affichage propres au Web. Le sujet est déve­lop­pé dans notre article sur la typo­gra­phie sur le Web.

Les composants : des éléments déjà construits

Un com­po­sant est un élé­ment d’interface nor­ma­li­sé et réuti­li­sable : un bou­ton, un champ de for­mu­laire, un mes­sage d’alerte, une carte de pré­sen­ta­tion. Selon le niveau de matu­ri­té du sys­tème, il peut être four­ni comme modèle dans une biblio­thèque de concep­tion, comme implé­men­ta­tion tech­nique dans le code, ou sous ces deux formes. Il ne se limite pas à son appa­rence au repos. Il décrit aus­si ses états : au sur­vol de la sou­ris, au moment du clic, lorsqu’il reçoit le focus cla­vier, c’est-à-dire quand la navi­ga­tion au cla­vier l’atteint, lorsqu’il est désac­ti­vé, ou lorsqu’une sai­sie est refusée.

Ces états sont pré­ci­sé­ment ce qu’une charte gra­phique tra­di­tion­nelle décrit rare­ment avec ce niveau de détail, car son objet n’est pas de docu­men­ter l’interaction. Le desi­gn sys­tem les asso­cie direc­te­ment au com­po­sant et, lorsqu’une biblio­thèque tech­nique est four­nie, son code les applique sans qu’il soit néces­saire de les recons­truire à chaque utilisation.

Les règles d’usage, la documentation et la gouvernance

Sans ce troi­sième ensemble, le sys­tème n’est qu’une réserve d’éléments. Les règles disent quand employer quoi : dans quel contexte, avec quelles com­bi­nai­sons, et sur­tout dans quels cas s’abstenir. Un exemple cou­rant tient en une ligne : un seul bou­ton prin­ci­pal par groupe d’actions, sinon plus rien ne hié­rar­chise l’action atten­due. La docu­men­ta­tion explique aus­si com­ment se com­por­ter quand l’élément dont on a besoin n’existe pas.

Dans les sys­tèmes les plus struc­tu­rés, une gou­ver­nance com­plète cette docu­men­ta­tion : elle indique qui peut pro­po­ser un nou­vel élé­ment, qui le valide et com­ment les modi­fi­ca­tions sont inté­grées sans créer de variantes concurrentes.

Un exemple public per­met de voir cette orga­ni­sa­tion en vrai. Le Sys­tème de Desi­gn de l’État, des­ti­né aux sites en .gouv.fr et aux appli­ca­tions mobiles de l’État, est consul­table libre­ment : il réunit des fon­da­men­taux (cou­leurs, typo­gra­phies, grille, espa­ce­ments), plus de cin­quante com­po­sants docu­men­tés, et des règles d’usage expli­cites, dont l’obligation d’employer un com­po­sant exis­tant plu­tôt que d’en créer un nou­veau. Les fon­da­tions, les com­po­sants et les règles qui encadrent leur uti­li­sa­tion y sont clai­re­ment organisés.

Ce qu’il résout : la répétition des décisions

La fonc­tion pre­mière d’un desi­gn sys­tem n’est pas de rendre une inter­face plus belle. Il répond à un pro­blème d’organisation : quand plu­sieurs per­sonnes pro­duisent ou font évo­luer dif­fé­rentes inter­faces, par­fois pen­dant plu­sieurs années, les mêmes déci­sions sont reprises à chaque fois et réin­ter­pré­tées au pas­sage. Quelqu’un recrée un bou­ton de mémoire, quelqu’un d’autre choi­sit un bleu voi­sin, un troi­sième réduit un espa­ce­ment pour que le conte­nu tienne. Chaque écart est minus­cule, aucun ne se remarque iso­lé­ment, et l’ensemble finit par ne plus se ressembler.

Les inter­ven­tions n’ont pas besoin d’être simul­ta­nées pour pro­duire cet effet. Une refonte, un module ajou­té deux ans plus tard, un pres­ta­taire rem­pla­cé : la suc­ces­sion suf­fit, la coor­di­na­tion en temps réel n’est pas le sujet. C’est d’ailleurs pour­quoi le pro­blème se mani­feste sur­tout par accu­mu­la­tion, long­temps après les déci­sions qui l’ont créé.

Le deuxième apport est la pro­pa­ga­tion : une déci­sion est prise une fois et s’applique par­tout. En contre­par­tie, une mau­vaise déci­sion se pro­page exac­te­ment de la même façon, ce qui rend l’arbitrage ini­tial plus lourd qu’il ne le serait sur un sup­port isolé.

Le troi­sième touche à la qua­li­té de fabri­ca­tion, notam­ment à l’accessibilité web. L’accessibilité et les états d’erreur peuvent être inté­grés direc­te­ment aux com­po­sants : niveau de contraste, focus cla­vier visible, libel­lé cor­rec­te­ment asso­cié à son champ, mes­sage d’erreur relié à la sai­sie fau­tive. Le tra­vail est fait une fois, dans le com­po­sant, au lieu d’être réin­ven­té à chaque for­mu­laire. Cela ne suf­fit pas à garan­tir un résul­tat acces­sible : l’assemblage des com­po­sants, l’ordre de lec­ture, les textes et les images relèvent de la page et non de la biblio­thèque, et un com­po­sant irré­pro­chable peut être employé de travers.

Ce qu’il coûte

Un desi­gn sys­tem se construit, se main­tient et s’adopte. Ce sont trois charges dis­tinctes, et la pre­mière est la plus visible mais rare­ment la plus lourde.

Le construire sup­pose de tran­cher, sou­vent pour la pre­mière fois, des ques­tions res­tées impli­cites : com­bien de niveaux de titres, quelle échelle d’espacement, quelles variantes de bou­ton sont légi­times et les­quelles ne le sont pas. Le main­te­nir sup­pose de suivre l’évolution du pro­duit, faute de quoi le sys­tème décrit un état qui n’existe plus. Un sys­tème que plus per­sonne ne met à jour devient faux, et un sys­tème faux est plus gênant que pas de sys­tème du tout : cha­cun croit pou­voir s’y fier, découvre l’écart au cas par cas, et se met à contourner.

L’adoption est la charge la moins anti­ci­pée. Un sys­tème que l’on contourne ne pro­duit aucun des béné­fices atten­dus, et il conti­nue pour­tant à coû­ter en main­te­nance. Pour qu’il soit employé, mieux vaut qu’il soit plus rapide de s’en ser­vir que de refaire à la main, ce qui sup­pose qu’il soit facile à trou­ver, à jour et docu­men­té dans les termes de ceux qui l’utilisent.

Reste une limite de nature : le desi­gn sys­tem pro­page ce qu’on lui donne. Il ne dis­pense pas de la réflexion de marque qui le pré­cède, et une iden­ti­té mal posée se retrouve sim­ple­ment appli­quée plus vite et plus uniformément.

Alors, en avez-vous besoin ?

La ques­tion n’est pas celle de votre taille, et elle ne se règle pas par une liste de condi­tions à rem­plir toutes ensemble. Elle porte sur la fré­quence à laquelle vous rejouez les mêmes déci­sions, et sur ce que cette répé­ti­tion vous coûte.

Les signaux qui indiquent qu’un sys­tème com­men­ce­rait à servir

➔ Les mêmes élé­ments sont recréés régulièrement.

➔ Des variantes presque iden­tiques com­mencent à apparaître.

➔ Plu­sieurs per­sonnes inter­viennent sur les interfaces.

➔ Les mêmes déci­sions doivent être appli­quées sur plu­sieurs sites ou produits.

➔ Une modi­fi­ca­tion glo­bale devient longue ou risquée.

Aucun de ces signaux ne rend à lui seul un desi­gn sys­tem com­plet néces­saire, et leur absence ne condamne per­sonne à l’improvisation. Une pers’onne seule sur un site deve­nu éten­du peut gagner à se consti­tuer une petite biblio­thèque cohé­rente ; une équipe de plu­sieurs per­sonnes sur un site vitrine stable n’en aura pas for­cé­ment l’usage. Ce qui compte est le rap­port entre ce que coûte le sys­tème et ce que coûte la répé­ti­tion qu’il évite : tant que le second reste infé­rieur au pre­mier, la réponse est non, et elle peut chan­ger plus tard.

Ce que vous avez déjà, sans l’appeler ainsi

Si vous gérez un site Word­Press avec un thème par blocs, une par­tie de cette logique est déjà en place, sous d’autres noms.

Les styles glo­baux de l’éditeur de site en reprennent le prin­cipe : une palette, des tailles de texte et d’autres choix visuels sont défi­nis à un seul endroit, puis appli­qués dans tout le site. Le méca­nisme est expli­cite dans la docu­men­ta­tion de Word­Press : les valeurs décla­rées dans le fichier theme.json du thème sont conver­ties en pro­prié­tés per­son­na­li­sées CSS, c’est-à-dire en variables réuti­li­sables du type --wp--preset--color--{slug}, char­gées aus­si bien côté public que dans l’éditeur. C’est bien le prin­cipe des tokens, appli­qué à l’échelle d’un site.

Les com­po­si­tions ajoutent une pre­mière couche de réuti­li­sa­tion : un ensemble de blocs est enre­gis­tré une fois puis réin­sé­ré ailleurs. Lorsqu’une com­po­si­tion est syn­chro­ni­sée, les modi­fi­ca­tions appor­tées à ses élé­ments com­muns se réper­cutent dans toutes ses occur­rences. Cer­tains conte­nus peuvent tou­te­fois res­ter modi­fiables loca­le­ment lorsque des sur­charges ont été pré­vues. Une com­po­si­tion n’est pas pour autant un com­po­sant au sens plein : elle cen­tra­lise sur­tout une struc­ture et sa mise en forme, sans défi­nir à elle seule des com­por­te­ments ni des états inter­ac­tifs. Une fois déta­chée de sa source, elle cesse de suivre les modifications.

Ce n’est donc pas un desi­gn sys­tem, et il n’y a pas lieu de le pré­sen­ter comme tel. À l’échelle d’un site vitrine, cela peut en revanche cou­vrir une grande part du besoin. Pour savoir où inter­ve­nir selon ce que vous cher­chez à chan­ger, entre réglages natifs, styles glo­baux et CSS, notre article Modi­fier l’apparence de son site Word­Press donne la méthode adap­tée à chaque cas.

Par quoi commencer, si vous voulez avancer

Trois pas suf­fisent à récu­pé­rer l’essentiel du béné­fice, et aucun n’exige d’outil particulier.

Écrire vos déci­sions au lieu de les retrou­ver. Les codes exacts de vos cou­leurs, le nom de vos polices, vos tailles de titres. Une page suf­fit, et elle rend ser­vice dès la pre­mière fois que quelqu’un d’autre pro­duit quelque chose pour vous.

Les nom­mer au lieu de les reco­pier. Sur un site Word­Press, cela veut dire ren­sei­gner la palette et les tailles dans les styles glo­baux, puis s’y réfé­rer, plu­tôt que de sai­sir une valeur de cou­leur bloc par bloc. Sur un site fait sur mesure, cela veut dire décla­rer des variables CSS nom­mées selon leur usage et les employer par­tout où la même déci­sion s’applique.

Réuti­li­ser au lieu de refaire. Dès qu’un ensemble d’éléments revient à l’identique sur plu­sieurs pages, il gagne à être enre­gis­tré une fois plu­tôt que recons­truit à chaque occurrence.

Vous n’avez pas besoin d’appeler cela un desi­gn sys­tem ni d’en construire un com­plet. Vous en appli­quez déjà le prin­cipe essen­tiel : prendre une déci­sion une fois, puis la réutiliser.

À retenir

Un desi­gn sys­tem n’est pas une charte gra­phique en plus gros, ni un sup­plé­ment esthé­tique. La charte fixe la manière dont une marque doit appa­raître ; le desi­gn sys­tem trans­forme une par­tie de ces règles en élé­ments réuti­li­sables pour construire des inter­faces, en trois grands ensembles : des fon­da­tions dont cer­taines déci­sions deviennent des valeurs nom­mées, des com­po­sants qui décrivent leurs dif­fé­rents états, et une docu­men­ta­tion qui encadre leur usage et leur évolution.

Il répond à un pro­blème pré­cis, qui n’est pas un pro­blème de goût : la répé­ti­tion des mêmes déci­sions, leur réin­ter­pré­ta­tion par des per­sonnes dif­fé­rentes, et le coût d’une modi­fi­ca­tion qui doit être repor­tée par­tout. Là où ce pro­blème n’existe pas, le sys­tème est une charge sans contre­par­tie, et il ne devient pas gra­tuit parce qu’on l’a construit une fois.

La ques­tion utile n’est donc pas « ai-je un desi­gn sys­tem », mais « com­bien me coûte, aujourd’hui, de reprendre les mêmes déci­sions ». Si la réponse est « peu », vos styles glo­baux et un peu de rigueur écrite vous emmè­ne­ront sou­vent plus loin qu’une biblio­thèque disproportionnée.

Image à la une : pho­to de Balázs Kétyi