{"id":7955,"date":"2021-07-27T07:00:22","date_gmt":"2021-07-27T05:00:22","guid":{"rendered":"https:\/\/stephaniewalter.design\/fr\/?p=7955"},"modified":"2021-09-05T14:34:13","modified_gmt":"2021-09-05T12:34:13","slug":"bien-concevoir-ses-composants-les-bases-dun-design-system-evolutif","status":"publish","type":"post","link":"https:\/\/stephaniewalter.design\/fr\/blog\/bien-concevoir-ses-composants-les-bases-dun-design-system-evolutif\/","title":{"rendered":"Bien concevoir ses composants, les bases d’un design system \u00e9volutif"},"content":{"rendered":"
Comment concevoir des syst\u00e8mes de composants flexibles r\u00e9utilisables et modulaires ? Des composants qui s\u2019adaptent \u00e0 la taille du navigateur ou leur contexte d\u2019affichages ? Des composants qui s\u2019adaptent au vrai contenu \u201cnon id\u00e9al\u201ds ? Des composants qui s\u2019adaptent aux diff\u00e9rents cas d\u2019usage des utilisatrices et utilisateurs ? Je vous propose aujourd\u2019hui un gros aper\u00e7u de mon processus de conception pour d\u00e9signer des syst\u00e8mes modulaires qui s\u2019adaptent \u00e0 la r\u00e9alit\u00e9 d\u2019un produit, aussi complexe soit elle. Cet article est tir\u00e9 d\u2019une conf\u00e9rence du m\u00eame nom dont vous trouverez la vid\u00e9o \u00e0 la fin.<\/p>\n
L\u2019article en long, vous pouvez naviguer plus rapidement dans les sections ici :<\/p>\n
J\u2019en profite pour vous rappeler que le contenu de cet article, les images et le design des slides ne sont pas libres de droits. Vous n\u2019avez normalement pas le droit de les r\u00e9utiliser sans mon autorisation. Donc soyez sympa, si vous voulez utilisez ce contenu, demandez-moi avant et citez cet article comme source. Merci.<\/em><\/small><\/p>\n Pour d\u00e9signer un syst\u00e8me \u00e9volutif, on veut tout d\u2019abord cr\u00e9er des composants r\u00e9utilisables. Pour cela, tout commence pour moi par l\u2019architecture d\u2019information<\/strong>\u2026 Au fil du temps, de mes lectures et travaux, j\u2019ai affin\u00e9 la fa\u00e7on dont je travaille qui est un m\u00e9lange de diff\u00e9rentes lectures et workshops, incluant :<\/p>\n L\u2019\u00e9tape z\u00e9ro de tout bon design pour moi est de faire sa recherche utilisateur en amont (oui, je sais, parfois ce n\u2019est pas toujours facile).<\/p>\n Quand la recherche utilisateur est bien faite, elle permet d\u2019extraire des besoins et des patterns du c\u00f4t\u00e9 des utilisatrices et utilisateurs. La recherche va donc permettre de guider ce qui sera dans vos pages et vos composants. <\/strong>Cela permettra \u00e9galement de vous aider \u00e0 faire des arbitrages en termes d\u2019importance sur la page ou dans le parcours de tel ou tel contenu (on y revient dans l\u2019\u00e9tape 2. sur la priorisation).<\/p>\n Comment faire sa recherche est en dehors du p\u00e9rim\u00e8tre de cet article, mais voil\u00e0 quelques pistes de questions \u00e0 vous poser pour vous guider :<\/p>\n Pour plus de questions \u201ctype\u201d, notamment lorsque vous faites des entretiens utilisateurs, vous pouvez consulter mon aide m\u00e9moire<\/a>.<\/p>\n C\u2019est l\u00e0 o\u00f9 une collaboration entre les \u00e9quipes de design plut\u00f4t c\u00f4t\u00e9 UI et les \u00e9quipes de recherche est tr\u00e8s importante.<\/p>\n Je suis une grande fan du livre de Abby Covert \u201cHow to make sense of any mess\u201d<\/span><\/a>. En g\u00e9n\u00e9ral, face \u00e0 un probl\u00e8me compliqu\u00e9, je commence par le d\u00e9couper en petits morceaux et tout mettre \u00e0 plat<\/strong>. Dans mon m\u00e9tier on appelle \u00e7a \u00ab\u00a0travailler l’architecture d’information\u00a0\u00bb<\/strong>. Et pour des composants, ces petits morceaux sont souvent les diff\u00e9rents types de contenus et de contenus dont je vais avoir besoin. Avant de designer le moindre composant, je commence donc par mod\u00e9liser les types de contenus dont je vais avoir besoin dans l\u2019interface au niveau des pages et de mes composants.<\/p>\n Au d\u00e9but, je faisais \u00e7a sous forme d\u2019une longue colonne de Post-it sur un mur, m\u00e9thode inspir\u00e9e de l\u2019atelier que Karen McGrane<\/span>. Comme je suis pass\u00e9e en remote \u00e0 plein temps depuis un an et demi, en ce moment c\u2019est sur miro. Mais le fond reste le m\u00eame :<\/p>\n Petite note : le mod\u00e8le de contenu m\u2019aide \u00e0 designer mes pages et composants. Mais il aide aussi en g\u00e9n\u00e9ral les \u00e9quipes de d\u00e9veloppement \u00e0 designer le back-end, les APIs et la structure de la base de donn\u00e9es. N\u2019h\u00e9sitez donc pas \u00e0 le partager.<\/p>\n Sur des composants plus compliqu\u00e9s, je vais parfois aussi lister les interactions<\/strong>. Ces interactions vont parfois cr\u00e9er des variantes des composants (mode lecture seule, \u00e9dition, etc.).<\/p>\n Quand le mod\u00e8le est long, je tague parfois certains attributs comme \u00e9tant des m\u00e9tadonn\u00e9es<\/strong>. Ce sont des attributs particuliers dont on se sert souvent pour classer, faire des listes, des recherches, des filtres, etc. Sur un site de recette de cuisine, on pense aux cat\u00e9gories, au co\u00fbt, au temps de pr\u00e9paration, etc.<\/em><\/p>\n Une fois que j\u2019ai ma liste d\u2019ingr\u00e9dients (haha) de ce dont est compos\u00e9 ce type de contenu, en g\u00e9n\u00e9ral je m\u2019int\u00e9resse \u00e0 la priorit\u00e9 des \u00e9l\u00e9ments qui le composent.<\/p>\n Quand on creuse un peu, on se rend compte qu\u2019une grosse partie de nos sites fonctionne sur un mod\u00e8le r\u00e9sum\u00e9 > d\u00e9tail<\/strong>. Et qu\u2019une grande partie des pages sont soit des listes de r\u00e9sum\u00e9s, soit des pages de d\u00e9tails. Quelques exemples :<\/p>\n Ai-je besoin de continuer ?<\/p>\n En g\u00e9n\u00e9ral je priorise les \u00e9l\u00e9ments \u00e0 l\u2019int\u00e9rieur de mon type de contenu du plus important en haut au moins important en bas. C\u2019est l\u00e0 o\u00f9 le faire sur un mur \u00e9tait pratique<\/p>\n \u00c0 partir de l\u00e0 j\u2019ai une bonne base pour :<\/p>\n D’une colonne de contenu class\u00e9 par priorit\u00e9 on peut cr\u00e9er des petits composants de \u00ab\u00a0r\u00e9sum\u00e9\u00a0\u00bb, des plus gros, voir une page enti\u00e8re<\/p><\/div>\n \u00c0 ce stade vous devez sans doute vous demander \u201cmais comment on d\u00e9cide ce qui est important ou pas?\u201d. On ne d\u00e9cide pas arbitrairement. On le fait en fonction des donn\u00e9es collect\u00e9es lors de la recherche utilisateur<\/strong> faite en amont (souvenez-vous, \u00e9tape 0).<\/p>\n Et s\u2019il y a des \u00e9l\u00e9ments pour lesquels l\u2019\u00e9quipe ne s’accorde pas sur la priorit\u00e9, c\u2019est souvent l\u00e0 qu’on ira creuser avec plus de recherche<\/strong>. Cela permet de mieux comprendre ce qui va impacter les d\u00e9cisions des utilisatrices et utilisateurs et leurs besoins.<\/p>\n Si je prends un exemple concret sur un projet un poil plus complexe que des sites de recette de cuisine\u2026 J\u2019ai un site avec des op\u00e9rations financi\u00e8res. Nous avons la page d\u00e9taill\u00e9e d’une op\u00e9ration. Mais nous avons aussi besoin de composants de \u201cnavigation\u201d qu\u2019on appelle \u201centity link item<\/span>\u201d qui permettra de lister les op\u00e9rations \u00e0 diff\u00e9rents endroits de l\u2019interface. Le mod\u00e8le de contenu de l’op\u00e9ration est tr\u00e8s compliqu\u00e9, car il va contenir beaucoup d\u2019\u00e9l\u00e9ments. Tellement compliqu\u00e9 qu\u2019au final, on va structurer et r\u00e9partir ces attributs de contenus en \u201csous types\u201d sur plusieurs pages de d\u00e9tails.<\/p>\n Du mod\u00e8le de contenu complet, au mod\u00e8le du composant, au composant.<\/p><\/div>\n \u00c0\u00a0partir de ma priorisation de contenus, je peux \u201cgarder\u201d la partie du mod\u00e8le de contenu<\/strong> qui va aider l\u2019utilisatrice \u00e0 d\u00e9cider de cliquer ou non sur cet \u00e9l\u00e9ment (ici c\u2019est la partie qui identifie l’op\u00e9ration) pour cr\u00e9er ce composant de liste \/ navigation qu\u2019on appelle chez nous \u201centity list item<\/span>\u201d.<\/p>\n En g\u00e9n\u00e9ral, on essaie de r\u00e9utiliser un maximum nos composants quand c\u2019est possible. Identifier o\u00f9 et comment pour factoriser les utilisations peut permettre de faire gagner par mal de temps aux \u00e9quipes<\/p>\n \u00c0 partir de l\u00e0 je me pose souvent la question de \u201cExiste-t-il des variations qui pourraient utiliser le m\u00eame composant ?\u201d. On peut imaginer diff\u00e9rents types de variations<\/p>\n La liste peut \u00eatre longue, ce ne sont que quelques exemples ici (plus d\u2019exemples dans la derni\u00e8re partie). \u00c0 vous d\u2019identifier les petites variations<\/strong> qui permettent de cr\u00e9er \u201cpresque\u201d le m\u00eame composant<\/strong> \u00e0 quelques d\u00e9tails pr\u00e8s et voir du coup si un composant g\u00e9n\u00e9rique avec des options peut fonctionner, plut\u00f4t que plusieurs composants. En g\u00e9n\u00e9ral, jeter un \u0153il au mod\u00e8le de contenu aide \u00e0 identifier ces cas.<\/p>\n Des mod\u00e8les pour les 4 types de contenus aux variantes de composants<\/p><\/div>\n Dans mon interface j\u2019ai en fait 4 types de contenus li\u00e9s qui vont avoir besoin d\u2019un composant lien : op\u00e9rations, contrats, contreparties et documents. Si on regarde le mod\u00e8le de contenu de ces diff\u00e9rents types, on se rend compte qu\u2019il y a pas mal de similitudes.<\/p>\n Au final on pourrait utiliser le m\u00eame composant, avec des variations.<\/p>\n Au-del\u00e0 des variations du composant li\u00e9es \u00e0 ses attributs et types de contenus, on peut aussi identifier que certains composants seront utilis\u00e9s dans diff\u00e9rents contextes<\/strong>. Par exemple, un composant de lien peut \u00eatre utilis\u00e9 dans une liste, mais peut-\u00eatre aussi dans des r\u00e9sultats de recherche. Le m\u00eame composant qui peut exister sur une appli web mais aussi sur App native mobile (donc optimisation au touch), sur un Google Nest Hub, Google TV, etc.<\/p>\n Sur mon site, il y a pleins d\u2019endroits o\u00f9 on va utiliser ce composant de navigation vers un type d\u2019entit\u00e9:<\/p>\n C\u2019est l\u00e0 o\u00f9 \u00e7a commence \u00e0 devenir fun : la recherche sur mon site existe dans une taille moyenne sur la page d\u2019accueil. Mais elle existe aussi dans une version \u201cpetite\u201d \u00e0 l\u2019int\u00e9rieur du site sur chaque page. Pour mon \u201centity link<\/span>\u201d, du coup j\u2019ai donc d\u00e9sormais non seulement 4 \u201cvariations\u201d mais \u00e9galement 2 tailles<\/p>\n 4 variations du composant et deux tailles (moyen et petit)<\/p><\/div>\n Je d\u00e9cris tout cela dans la conf\u00e9rence et cet article de mani\u00e8re lin\u00e9aire. Mais sur un projet ce n\u2019est pas le cas. Souvent c\u2019est un processus it\u00e9ratif<\/strong> o\u00f9 on r\u00e9fl\u00e9chit \u00e0 plusieurs fois variations et similarit\u00e9s en m\u00eame temps.<\/p>\n Mon composant \u201centity link<\/span>\u201d pourrait \u00eatre r\u00e9utilis\u00e9 pour la page de r\u00e9sultats de recherche. Mais nous nous sommes rendu compte qu\u2019en termes de priorit\u00e9 utilisateur, pour les r\u00e9sultats de recherche, il nous fallait afficher un peu plus d\u2019informations que la version par d\u00e9faut. C\u2019est li\u00e9 au fait que ce composant dans les r\u00e9sultats de recherche peut \u00eatre filtr\u00e9. Il nous faut donc un peu plus d\u2019informations.<\/p>\n Nous avons \u00e9tendu le mod\u00e8le <\/strong>pour y inclure plus d\u2019\u00e9l\u00e9ments qui \u00e9taient consid\u00e9r\u00e9s comme priorit\u00e9 plus basse pour cr\u00e9er une variante.<\/p>\n \u00c9tendre la priorit\u00e9 du mod\u00e8le sur des variations en ajoutant des attributs de la liste<\/p><\/div>\n Dans notre design syst\u00e8me, nous avons maintenant une variante qui affiche un peu plus d\u2019informations que la version par d\u00e9faut et qui est utilis\u00e9e pour les r\u00e9sultats de recherche.<\/p>\n 4 variations du composant de base, et 4 nouvelles variations pour les r\u00e9sultats de recherche<\/p><\/div>\n Bon je m\u2019arr\u00eate l\u00e0 pour les exemples, mais sur le projet ce composant a encore quelques variations possibles.<\/p>\n Le principe reste le m\u00eame :<\/p>\n Aujourd\u2019hui avec le design syst\u00e8me en place sur mon projet, je ne fais plus vraiment beaucoup de wireframes d\u00e9taill\u00e9s des composants. J\u2019ai plut\u00f4t tendance \u00e0 faire l\u2019inventaire et prioriser<\/strong>. Ensuite, je reprends les attributs sur miro pour cr\u00e9er des zonings tr\u00e8s basse fid\u00e9lit\u00e9 de ce qui sera dans le composant. Puis je passe au design dans Sketch.<\/p>\n J\u2019ai volontairement simplifi\u00e9 les exemples ci-dessus pour mettre l\u2019accent sur le processus. L\u2019\u00e9tape \u201ctechnique\u201d entre est celle du \u201czoning\u201d. Elle est assez minimaliste sur ce composant tr\u00e8s simple et ressemble un peu \u00e0 \u00e7a:<\/p>\n Du mod\u00e8le de contenu, au zoning au composant final<\/p><\/div>\n On peut aussi utiliser ce mod\u00e8le de contenu pour d\u00e9signer des pages de d\u00e9tails en responsive par exemple<\/strong>. On arrive \u00e0 un zoning pr\u00e9cis qui permet ensuite souvent de passer assez rapidement \u00e0 l\u2019UI dans Sketch, surtout si on a une grosse partie des composants d\u00e9j\u00e0 dans le syst\u00e8me :<\/p>\n De la priorisation de contenu au zoning de 2 pages, une page de d\u00e9tails et une page de \u00ab\u00a0liste\u00a0\u00bb<\/p><\/div>\n D\u2019ailleurs c\u2019est une partie des m\u00e9thodes que j\u2019enseigne dans ma formation responsive \u00e0 mes \u00e9tudiantes et en workshop en petit comit\u00e9. Si vous \u00eates int\u00e9ress\u00e9s par ce type d\u2019enseignement pour votre conf\u00e9rence ou master class, envoyez-moi un e-mail<\/a>.<\/p>\n Bien s\u00fbr, ce travail ne se fait pas en silo mais est en collaboration avec mon \u00e9quipe de d\u00e9veloppement. Nous discutons pas mal avec l\u2019\u00e9quipe de d\u00e9veloppement<\/strong> pour ce type de composants, que ce soit sur le contenu ou la faisabilit\u00e9 technique.<\/p>\n Mais ce qui est clair aujourd\u2019hui dans ma t\u00eate (et celle de mon \u00e9quipe) ne le sera pas forc\u00e9ment dans 3 semaines ou un mois quand on va commencer vraiment le d\u00e9veloppement. Je documente donc beaucoup de choses pour ces composants :<\/p>\n Apr\u00e8s tout ce travail sur le mod\u00e8le de contenu et les variations, le r\u00e9sultat final est un seul et unique composant, avec diff\u00e9rentes options qui permet de g\u00e9rer tous ces cas. Toute la complexit\u00e9 du composant a pu \u00eatre r\u00e9sum\u00e9e en 4 grosses zones que l\u2019on remplit en fonction des options.<\/p>\n Dans mon exemple, j\u2019ai 2 versions : medium et small du composant. Pour la version small, on peut la faire en utilisant des techniques de responsive web design<\/strong>: utiliser des media queries<\/strong> pour g\u00e9rer des variations de composant en fonction de la taille du viewport.<\/p>\n Le truc vraiment sympa et tout nouveau qui va permettre de pousser la modularit\u00e9 un cran plus loin avec les container queries.<\/strong>Au lieu d\u2019adapter en fonction de la taille du viewport (media queries), on va pouvoir adapter le composant en fonction de la taille du container <\/strong>dans lequel on va le mettre. La bonne nouvelle c\u2019est que cette spec arrive bient\u00f4t dans le navigateur!!<\/a> Si vous n\u2019avez pas la patience d\u2019attendre, il est possible de les simuler avec beaucoup de JS<\/a> (ce que nous faisons actuellement sur mon projet en attendant que les navigateurs impl\u00e9mentent Container queries.)<\/p>\n \u00c0 gauche les media queries, permettent de modifier un composant en fonction de la taille du viewport. \u00c0 droite, les container queries, permettent de modifier le composant en fonction de la taille de son parent \/ contenaire<\/p><\/div>\n Mais container queries n\u2019est pas la seule chose qui permet de cr\u00e9er des composants capables de s\u2019adapter tout seul en fonction de l\u2019espace disponible. Pas mal de propri\u00e9t\u00e9s CSS plut\u00f4t bien support\u00e9es permettent d\u2019aller tr\u00e8s loin aujourd\u2019hui dans la modularit\u00e9: D\u2019ailleurs, en 2018 d\u00e9j\u00e0, Jen Simmons<\/a> dans sa conf\u00e9rence \u201cEverything You Know About Web Design Just Changed<\/a><\/span>\u201d pr\u00e9sentait d\u00e9j\u00e0 la notion de Intrinsic Web Design<\/strong><\/span>. Au lieu de changer de style en fonction de la taille du navigateur, elle propose de cr\u00e9er des composants dont la mise en page s’adapte automatiquement aux conditions id\u00e9ales du navigateur. Elle y parle entre autres de Si je reprends mon exemple de site de restaurant, je pourrai avoir un composant \u201ccarte\u201d qui est capable de s\u2019adapter de mani\u00e8re horizontale ou verticale, \u00e0 l\u2019espace qui lui est d\u00e9di\u00e9 gr\u00e2ce \u00e0 \nDesign de composants r\u00e9utilisables<\/h2>\n
\n
0. Faire sa recherche utilisateur<\/h3>\n
\n
1. Travailler l’architecture d\u2019information et le un mod\u00e8le de contenu<\/h3>\n
\n

2. Tris de cartes pour classer et prioriser<\/h3>\n
Un mod\u00e8le R\u00e9sum\u00e9 > D\u00e9tail<\/strong><\/h4>\n
\n

\n
Utilisez votre recherche utilisateur !<\/strong><\/h4>\n
Exemple sur un vrai projet<\/strong><\/h4>\n
3. Identifier les variations et composants similaires<\/h3>\n
\n
4. Identifier les contextes de r\u00e9utilisation<\/h3>\n
\n
Variations et similarit\u00e9s : \u2028same player, play again !<\/strong><\/h4>\n
\n
Du mod\u00e8le de contenu aux zonings<\/h3>\n
Documentation et relation avec l\u2019\u00e9quipe de d\u00e9veloppement<\/h3>\n
\n


G\u00e9rer les variations d\u2019un point de vue technique<\/h3>\n
flexbox<\/code>, grid<\/code>, clamp()<\/code>, etc.<\/p>\ngrid layout<\/code>.<\/p>\nflexbox<\/code> et clamp()<\/code> (aucune media queries ici). Et si vous \u00eates curieuses de comment \u00e7a fonctionne techniquement, Geoffrey Crofte a fait un article d\u00e9taill\u00e9 :How to Make a Media Query-less Card Component<\/span><\/a><\/p>\n
\n1<\/p>\n