{"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 \n\n<\/p>\n\n Ressources pour aller plus loin<\/p>\n Pour moi, si on veut arriver \u00e0 cr\u00e9er des composants r\u00e9utilisables, il faut sortir de l\u2019obsession du \u201cpixel perfect\u201d et accepter la flexibilit\u00e9 des navigateurs. \u2028\u2028Designer dans les outils, \u2028D\u00e9cider dans le navigateur ! C\u2019est pour \u00e7a que je pr\u00e9f\u00e8re voir le r\u00e9sultat final le plus t\u00f4t possible dans un navigateur, quitte \u00e0 revenir sur mon design si besoin si des choses ne fonctionnent pas visuellement.<\/p>\n La derni\u00e8re \u00e9tape pour moi est donc cruciale : un retour ensemble en peer review avec les \u00e9quipes de d\u00e9veloppement et de design<\/strong> pour discuter et voir le comportement r\u00e9el du composant dans le navigateur. Et ajuster si besoin.<\/p>\n En temps normal c\u2019est en face \u00e0 face qu\u2019on faisait \u00e7a. Mais avec la situation sanitaire, nous faisons \u00e7a via partage d\u2019\u00e9cran et Skype<\/span>. Parfois j\u2019adapte l\u00e9g\u00e8rement le design en fonction des retours des \u00e9quipes de d\u00e9veloppement. Parfois on change directement certains paddings ou tailles dans le navigateur.<\/p>\n Au final c\u2019est une collaboration<\/strong> o\u00f9 le composant Sketch<\/span> sert surtout de r\u00e9f\u00e9rence. Mais ce qui compte, c\u2019est son impl\u00e9mentation finale, d\u2019un commun accord, dans le navigateur.<\/p>\n Pour m\u2019assurer que mes composants sont \u00e9volutifs, je fais non seulement attention \u00e0 leur r\u00e9utilisabilit\u00e9, mais \u00e9galement au fait qu\u2019ils vont pouvoir s\u2019adapter \u00e0 diff\u00e9rentes densit\u00e9s de contenu<\/strong> si n\u00e9cessaire.<\/p>\n Quand le contenu est g\u00e9n\u00e9r\u00e9 par des utilisatrices et utilisateurs, certains attributs peuvent parfois ne pas \u00eatre remplis<\/strong>, manquants<\/strong> ou ne pas exister pour certaines variantes.<\/p>\n Comment mon composant de \u201ccarte de recette de cuisine\u201d va-t-il se comporter s\u2019il n\u2019y a par exemple pas d\u2019image ?<\/p>\n Quelle que soit la d\u00e9cision de design, mon \u00e9quipe de d\u00e9veloppement va sans doute me poser la question. Cela leur permet d’anticiper et de construire un HTML\/CSS flexible pour le composant.<\/p>\n Une note de 0 parce que personne n’a \u00e9mis d’avis sur la recette n’est PAS la m\u00eame chose qu’une note de 0 parce que tout le monde d\u00e9teste la recette ! Que fait-on ?<\/p>\n La r\u00e9ponse d\u00e9pend de pleins de crit\u00e8res. Mais c\u2019est le genre de chose que l\u2019on va devoir anticiper pour cr\u00e9er des composants r\u00e9utilisables qui peuvent s\u2019adapter \u00e0 tout type de contenus.<\/p>\n Je viens de vous donner des exemples de \u201cpas\u201d ou \u201cpas assez\u201d de contenus. Une autre question que j\u2019ai tendance \u00e0 me poser est : que se passe-t-il s\u2019il y a plus, ou trop de contenu<\/strong>?<\/p>\n Par exemple, si mon composant de \u201cListe de favoris\u201d \u00e0 40 \u00e9l\u00e9ments, on fait quoi ?<\/p>\n L\u00e0 encore, \u00e7a d\u00e9pend de pleins de choses, mais il faut le pr\u00e9voir.<\/p>\n Parfois, il faut \u00e9galement g\u00e9rer la densit\u00e9 du contenu \u00e0 l\u2019int\u00e9rieur du composant<\/strong>.<\/p>\n Si je reprends mon exemple de recette de cuisine, que doit-on faire si le titre a besoin de 2 lignes. Il prend 2 lignes. Okay, jusque-l\u00e0 \u00e7a parait \u00e9vident. Mais comment le reste du composant va-t-il se comporter ?<\/p>\n Des exemples comme \u00e7a, j\u2019en ai pleins dans mon design syst\u00e8me<\/p>\n Voici quelques conseils pour vous aider \u00e0 anticiper ces cas. On en revient tr\u00e8s souvent \u00e0 la m\u00eame chose : la discussion entre \u00e9quipes de design et de d\u00e9veloppement.<\/p>\n Finalement, ce qui est \u00e0 retenir : Je n’ai pas besoin de les \u00ab\u00a0designer\u00a0\u00bb tous, mais surtout de \u00ab\u00a0d\u00e9cider\u00a0\u00bb de ce qui va se passer et de le communiquer \u00e0 l’\u00e9quipe de d\u00e9veloppement. Une grosse partie de notre interface sont des cartes dans lesquelles sont charg\u00e9s diff\u00e9rents types de contenus. J\u2019ai donc en plus, plusieurs \u00e9tats de \u201cpopulation de donn\u00e9es\u201d : chargement<\/strong>, pas de donn\u00e9es<\/strong> (\u00e9tat vide), erreur<\/strong>. Ces \u00e9tats sont \u201cg\u00e9n\u00e9riques\u201d et les m\u00eames quel que soit le contenu. Je n\u2019ai pas besoin, pour chaque nouvelle carte, de \u201credesigner\u201d ces \u00e9tats.<\/p>\n Pour le moment j’ai surtout parl\u00e9 de composants \u201cstatiques\u201d avec peu d\u2019interactions. Mais bon nombre de composants d\u2019un syst\u00e8me sont des composants de navigation, de recherche, de formulaire avec bien plus d\u2019interactions que juste un clic sur une carte.<\/p>\n Ces composants vont souvent avoir plusieurs \u00e9tats qu\u2019il va falloir pr\u00e9voir en fonction de diff\u00e9rents contextes<\/p>\n La 1e chose \u00e0 laquelle on pense, quand on dit \u201cinteraction\u201d\u2019 c\u2019est les interactions avec les \u00e9l\u00e9ments de formulaire. Un \u201csimple\u201d composant de champ texte n\u2019est au final jamais aussi simple, puisqu\u2019on va devoir pr\u00e9voir beaucoup d\u2019\u00e9tats diff\u00e9rents. Par exemple :<\/p>\n Et puis on va avoir les \u00e9tats de validation, par exemple<\/p>\n Tout cela, multipli\u00e9 par le nombre de composants de formulaires, \u00e7a commence \u00e0 faire pas mal de choses \u00e0 ne pas oublier.<\/p>\n Et plus le composant sera compliqu\u00e9, plus on aura d\u2019interactions \u00e0 pr\u00e9voir.<\/p>\n Et n\u2019oubliez pas la navigation au clavier<\/strong>, tr\u00e8s utile pour des questions d\u2019accessibilit\u00e9 mais \u00e9galement souvent pour des utilisatrices avanc\u00e9es.<\/p>\n Voici un exemple, sur un composant de menu d\u00e9roulant :<\/p>\n Il en est de m\u00eame pour les interactions au toucher<\/strong>. Parfois elles peuvent \u00eatre diff\u00e9rentes d\u2019une interaction classique. Par exemple : le carrousel d\u2019images doit-il fonctionner au swipe ? L\u00e0 encore, pas mal de choses \u00e0 discuter avec les \u00e9quipes de dev.<\/p>\n Une grosse partie de nos outils de conception nous obligent encore \u00e0 concevoir des images statiques de \u00ab\u00a0ce \u00e0 quoi le produit ressemblera\u201d. Cela rend parfois la communication d\u2019\u00e9tats tr\u00e8s interactifs un peu compliqu\u00e9e. \u00c7a avance un peu (avec certaines mises \u00e0 jour de Figma<\/span>), on va vers plus en plus d\u2019interactivit\u00e9.<\/p>\n Certains de nos livrables \u201cUX\u201d peuvent \u00e9galement servir aux \u00e9quipes de d\u00e9veloppement pour communiquer les interactions.<\/p>\n C\u2019est le cas par exemple de tout ce qui est task flow et user flows <\/strong>(qu\u2019on transforme en screenflow quand on y ajoute les \u00e9crans). Ils permettent aux \u00e9quipes de dev et \u00e0 mon testeur de mieux comprendre comment vont se comporter les composants, vont s\u2019enchainer les vues et \u00e9crans, etc.<\/p>\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
<\/p>\n2. Tris de cartes pour classer et prioriser<\/h3>\n
Un mod\u00e8le R\u00e9sum\u00e9 > D\u00e9tail<\/strong><\/h4>\n
\n
<\/p>\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
<\/p>\n
<\/p>\nG\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\n
Designer dans les outils, \u2028D\u00e9cider dans le navigateur !<\/h4>\n
Mon travail en tant que designer est de designer ces composants dans leurs \u201cmise en page id\u00e9ale\u201d. Mes \u00e9quipes de d\u00e9veloppement se chargent ensuite de fournir au navigateur les guidelines CSS pour se rapprocher autant que possible. Mais l\u2019impl\u00e9mentation finale reste \u00e0 la discr\u00e9tion du navigateur.<\/p>\nVariations et adaptations \u00e0 diff\u00e9rentes densit\u00e9s de contenus<\/h2>\n
Attributs de contenus manquants<\/h3>\n
\n
Sur ce m\u00eame composant, que se passe-t-il s’il n’y a pas (encore) de valeur<\/strong> pour les votes ?<\/p>\n\n
<\/p>\nPlus de contenu qu\u2019initialement pr\u00e9vu<\/h3>\n
\n
<\/p>\nDes attributs de contenu plus longs que pr\u00e9vu<\/h3>\n
\n
<\/p>\n\n
Comment anticiper le contenu flexible<\/h3>\n
\n
<\/p>\nChargement, population de donn\u00e9es, erreurs et l’absence de donn\u00e9es<\/h3>\n
J’essaie g\u00e9n\u00e9ralement de documenter la fa\u00e7on dont les composants sont cens\u00e9s fonctionner \u00e0 un niveau g\u00e9n\u00e9rique dans notre \u201cstyleguide\u201d<\/strong> (sur Sketch<\/span>). Les messages d\u2019erreur et cas vide quant \u00e0 eux sont document\u00e9s au cas par cas dans le ticket Jira. Nous avons \u00e9galement maintenant une checklist pour ne pas oublier des \u00e9tats quand on r\u00e9dige les tickets techniques Jira.<\/p>\nVariations et adaptations li\u00e9es \u00e0 l\u2019interactivit\u00e9 et au contexte d\u2019usage<\/h2>\n
Pensez \u00e0 diff\u00e9rents \u00e9tats interactifs<\/h3>\n
\n
\n
<\/p>\nPensez \u00e0 la navigation clavier, touch et autres interactions<\/h3>\n
Souvent, c\u2019est encore une fois une collaboration avec les \u00e9quipes de d\u00e9veloppement, car l\u2019impl\u00e9mentation n\u2019est pas toujours facile.<\/p>\nLes \u201clivrables\u201d UX pour communiquer les interactions aux \u00e9quipes de d\u00e9veloppement<\/h3>\n