{"id":7841,"date":"2021-03-02T20:41:45","date_gmt":"2021-03-02T19:41:45","guid":{"rendered":"https:\/\/stephaniewalter.design\/fr\/?p=7841"},"modified":"2021-03-03T09:25:47","modified_gmt":"2021-03-03T08:25:47","slug":"design-et-performance-ces-cas-oublies","status":"publish","type":"post","link":"https:\/\/stephaniewalter.design\/fr\/blog\/design-et-performance-ces-cas-oublies\/","title":{"rendered":"Design et performance : ces cas oubli\u00e9s"},"content":{"rendered":"
En g\u00e9n\u00e9ral, les \u00e9quipes de design livrent l\u2019\u00e9cran dans un \u00ab\u202f\u00e9tat parfait\u202f\u00bb. C\u2019est l\u2019\u00e9cran final, une fois que tout est bien charg\u00e9, avec toutes les bonnes donn\u00e9es, les bonnes images, rien ne manque, tout s\u2019est bien d\u00e9roul\u00e9. Youpi. Et ce qu\u2019il se passe avant, durant ces quelques millisecondes (ou parfois secondes) de chargement est souvent laiss\u00e9 \u00e0 l\u2019appr\u00e9ciation de l\u2019\u00e9quipe de d\u00e9veloppement. Tout comme ce qui se passe s\u2019il manque une donn\u00e9e, qu\u2019une serveur met du temps \u00e0 r\u00e9pondre, r\u00e9pond une erreur, une ressource manquante, etc. Designer ces cas oubli\u00e9s\u202fpermet grandement d\u2019am\u00e9liorer la collaboration designer \/ d\u00e9veloppeurs sur des th\u00e9matiques et d\u2019am\u00e9liorer l\u2019exp\u00e9rience utilisateur.<\/p>\n
Voici le transcript de ma conf\u00e9rence sur ce sujet \u00e0 We Love Speed 2021<\/a><\/span>. Vous pouvez aller directement \u00e0 la partie \u00ab slides<\/span><\/a> \u00bb et \u00e0 la partie \u00ab vid\u00e9o en Replay<\/a> \u00bb si vous le souhaitez.<\/p>\n Tout commence… par une page vide<\/strong>. Et ensuite, quoi ?<\/p>\n Eh bien, en g\u00e9n\u00e9ral, vous ne voulez pas attendre que la page enti\u00e8re soit charg\u00e9e pour afficher quelque chose<\/strong>. C\u2019est l\u00e0 que mon travail de designeuse va g\u00e9n\u00e9ralement vous aider.<\/strong><\/p>\n Car souvent, la premi\u00e8re chose \u00e0 laquelle on pense quand on dit performance, c\u2019est ce qu\u2019il se passe pendant le chargement du contenu.<\/p>\n Si vous vous int\u00e9ressez un peu \u00e0 la performance, l’une des premi\u00e8res consignes dont vous avez d\u00fb entendre parler est l\u2019optimisation du \u201ccritical rendering path<\/span><\/strong>\u201d. Cela signifie que lorsqu’une page se charge, on veut en g\u00e9n\u00e9ral afficher aux utilisatrices et utilisateurs en priorit\u00e9 \u00ab\u00a0le contenu qui leur permettra de rester suffisamment longtemps pour que le reste de la page ait le temps de se charger.<\/p>\n Priorit\u00e9 de contenu : faites votre recherche utilisateur<\/p><\/div>\n Mon travail est donc de designer une solide architecture d’information<\/strong> pour ces pages pour que ce qui s\u2019affiche en haut soit suffisamment int\u00e9ressant pour que les personnes restent le temps que le reste de la page se charge.<\/p>\n Il n’y a pas de recette \u00ab\u00a0magique\u00a0\u00bb pour y parvenir : vous devez comprendre leurs besoins <\/strong>et d\u00e9finir des priorit\u00e9s d’affichage<\/strong> de votre page : pourquoi visitent-elles cette page, que veulent-elles accomplir ?<\/p>\n Par exemple : s’il s’agit d’un article<\/strong>, le titre<\/strong> et l’introduction<\/strong> doivent \u00eatre affich\u00e9s le plus rapidement possible afin que les visiteuses et visiteurs puissent \u00ab\u00a0au moins\u00a0\u00bb se faire une premi\u00e8re id\u00e9e de \u00ab\u00a0est-ce que je veux continuer \u00e0 lire ceci ou est-ce que je retourne d’o\u00f9 je viens ?<\/p>\n Il existe des m\u00e9thodes d\u2019UX design qui peuvent vous aider \u00e0 \u00ab\u00a0hi\u00e9rarchiser\u00a0\u00bb ce contenu :<\/p>\n Il va ensuite falloir arriver \u00e0 faire en sorte que la partie technique<\/strong> qui permet de construire la page soit en ad\u00e9quation avec cette priorit\u00e9 de contenus<\/strong>. La premi\u00e8re \u00e9tape consiste donc g\u00e9n\u00e9ralement \u00e0 aller voir l’\u00e9quipe de d\u00e9veloppement et \u00e0 identifier, \u00e0 partir de cette \u00ab\u00a0priorit\u00e9\u00a0\u00bb, ce qui peut prendre du temps pour \u00eatre r\u00e9ellement charg\u00e9.<\/p>\n Il s’agit g\u00e9n\u00e9ralement d’une discussion ouverte sur le fonctionnement de la page. Surtout pour les applications web. Parce que, avec une tonne de JavaScript et de micro-services, ce n’est pas toujours aussi simple que le classique \u00ab\u00a0pages rendues c\u00f4t\u00e9 serveur PHP\u00a0\u00bb d\u2019un site WordPress comme celui-l\u00e0.<\/p>\n Une fois que je comprends les contraintes techniques, je designe ma strat\u00e9gie de chargement <\/strong>pour cette page et ce contenu. J\u2019essaie d’imaginer comment la page va se charger en fonction de ces contraintes.<\/p>\n Je communique cela \u00e0 mes \u00e9quipes de dev \u00e0 l\u2019aide d\u2019un sch\u00e9mas de chargement<\/strong>\u00a0(ou loading flow<\/span>). L’id\u00e9e est de montrer les diff\u00e9rentes \u00e9tapes de chargement.<\/p>\n Bien s\u00fbr, si la page se charge rapidement, l’utilisatrice ne sera pas consciente de ces \u00e9tapes car elles peuvent se d\u00e9rouler tr\u00e8s rapidement. Mais si la page se charge plus lentement, cela permet d’\u00e9viter un \u00e9cran vide.<\/p>\n Voici un exemple: On peut d\u00e9couper cet exemple en 5 \u00e9tapes au niveau du chargement. Sur cette page, la premi\u00e8re chose que nous affichons c\u2019est une coquille compos\u00e9e des \u00e9l\u00e9ments statiques<\/strong> (comme le logo, les fonds). Ensuite, nous chargeons le contenu statique<\/strong> (navigation).<\/p>\n L\u2019\u00e9tape suivante consiste \u00e0 afficher les titres<\/strong> des pages et des sections. Cela aide les utilisatrices \u00e0 savoir qu’elles sont sur la bonne page).<\/p>\n Vous vous souvenez que je vous ai dit que j’avais besoin de comprendre comment la page est construite ? C’est l\u00e0 que j’ai ma premi\u00e8re \u00ab\u00a0limitation technique\u00a0\u00bb (pour l’instant) :<\/p>\n Cela signifie que, en fonction de diff\u00e9rents param\u00e8tres, il peut arriver qu’un contenu d’une tuile moins prioritaire (donc plus bas sur la page) \u00ab\u00a0arrive\u00a0\u00bb avant dans le navigateur. Mais je ne peux rien y faire.<\/p>\n La strat\u00e9gie est donc la suivante :<\/p>\n L\u00e0 encore, ce n’est pas id\u00e9al mais c’est une contrainte technique.<\/p>\n Si j\u2019ai des m\u00e9triques<\/strong>, j\u2019essaie de les ajouter sur ces sch\u00e9mas de chargement. Voici ci-dessous un exemple du flux de chargement d’une application native. L’une des mesures que nous avons est que nous souhaitons afficher les 10 premiers \u00e9l\u00e9ments dans les 3 secondes. Ce sch\u00e9ma documente donc la mani\u00e8re dont le contenu est cens\u00e9 se charger, avec les diff\u00e9rentes m\u00e9triques et parcours.<\/p>\n Les flux de chargement c\u2019est bien sympa, mais c\u2019est juste un livrable de design pour nous aider \u00e0 communiquer avec les \u00e9quipes de dev. La derni\u00e8re \u00e9tape consiste \u00e0 tester tout \u00e7a une fois impl\u00e9ment\u00e9 dans le navigateur. Testez<\/strong> dans de vrais navigateurs, de vraies applications, diff\u00e9rentes conditions de r\u00e9seau et affinez les r\u00e9glages. Car vous pouvez designer autant de sch\u00e9mas que vous le souhaitez, mais vous aurez encore quelques ajustements \u00e0 faire<\/strong>.<\/p>\n \u00c7a, c\u2019\u00e9tait le meilleur sc\u00e9nario de \u00ab sous s\u2019est bien charg\u00e9. Mais parfois, les choses tournent mal pendant le chargement. En tant que designer, je dois \u00e9galement penser \u00e0 tous ces cas d\u2019erreur.<\/p>\n Comme souvent dans mon processus de concept, ma premi\u00e8re \u00e9tape est g\u00e9n\u00e9ralement de parler \u00e0 l’\u00e9quipe de d\u00e9veloppement pour identifier ce qui pourrait mal tourner. Dans le cas d\u2019erreurs, j\u2019essaie d\u2019identifier :<\/p>\n En g\u00e9n\u00e9ral, le premier type d’erreur auquel vous devez penser se situe au niveau de la page<\/strong>. Quelque chose s’est mal pass\u00e9 et vous ne pouvez pas charger le contenu de la page. Pensez par exemple aux pages 404. Si c\u2019est possible, vous souhaitez garder la personne sur le site.<\/p>\n Dans mon exemple de site plus haut, si l’API n\u2019a pas r\u00e9pondu, nous pouvons charger le squelette de la page. <\/strong>Mais nous ne pouvons pas charger les tuiles.<\/strong> J\u2019ai donc un petit message d\u2019erreur. Malheureusement ici, les utilisatrices ne peuvent pas faire grand-chose (sauf r\u00e9essayer ou revenir plus tard)<\/p>\n Ici mon but est de faire comprendre que la page a fini de charger, mais qu\u2019il y a eu un souci.<\/p>\n Dans mon cas, puisque nous avons une API qui charge le contenu de chaque composant dans une tuile, je peux \u00e9galement avoir une erreur au niveau du composant<\/strong>.<\/p>\n Dans ce cas, nous informons l\u2019utilisatrice que la tuile n\u2019a pas charg\u00e9 pour faire la diff\u00e9rence avec un \u00ab la tuile est charg\u00e9e mais n\u2019a pas de contenu \u00bb (voir section suivante). Dans mon cas, la personne ne peut encore une fois h\u00e9las rien faire<\/strong> (\u00e0 part attendre ou revenir).<\/p>\n Mais parfois, parfois les gens peuvent faire quelque chose. Par exemple, sur un projet d\u2019application mobile de vid\u00e9o surveillance, il pouvait y avoir un souci avec le wifi. Dans ce cas, nous encourageons les personnes \u00e0 v\u00e9rifier la connexion, voir red\u00e9marrer la box.<\/p>\n Voici donc quelques bonnes pratiques g\u00e9n\u00e9riques <\/strong>pour la gestion des messages d’erreur :<\/p>\n Une fois ces deux types de messages design\u00e9s, je les ajoute dans mes sch\u00e9mas de chargement de contenu. Dans mon design system, je documente \u00e9galement les \u00e9tats au niveau des composants. Ainsi, mon composant \u00ab\u00a0tuile\u00a0\u00bb a maintenant<\/p>\n Une autre chose que nous avons tendance \u00e0 oublier<\/strong> quand on design, c\u2019est est ce qui se passe quand il n’y a pas de contenu.<\/strong> Le but est d’aider \u00e0 faire comprendre comprendre que le contenu s\u2019est bel et bien charg\u00e9, mais que cette partie n\u2019a pas (encore) de contenu<\/p>\n Ces \u00e9tats qu\u2019on appellera \u00e9tats vides<\/strong>\u00a0peuvent \u00eatre des opportunit\u00e9s de design int\u00e9ressantes. Par exemple, si la recherche qui n’aboutit \u00e0 aucun r\u00e9sultat<\/strong>, vous pourriez proposer des alternatives<\/strong> comme le fait DrMarteens<\/span> (le top des cat\u00e9gories et des produits les plus vendus). Le but est que la personne reste sur le site et continue \u00e0 naviguer malgr\u00e9 le manque de contenu.<\/p>\n Dans une application de type liste de t\u00e2ches<\/strong>, le fait de ne plus avoir de t\u00e2ches est une \u00ab bonne \u00bb chose. F\u00e9licitez les gens, car g\u00e9n\u00e9ralement les personnes sont heureuses d\u2019avoir termin\u00e9 toute leur t\u00e2che (ou lu tous leurs mails). \u00c7a peut \u00eatre un \u00e9cran qui peut avoir plus ou moins de personnalit\u00e9<\/strong> en fonction de votre marque \/ produit. Mais l\u00e0 encore, attention de rester dans le ton de votre marque.<\/p>\n Si le contenu est un \u00ab\u00a0contenu g\u00e9n\u00e9r\u00e9 par les utilisatrices et utilisateurs<\/strong>\u00ab\u00a0, vous pouvez utiliser cet \u00e9tat vide comme une opportunit\u00e9 d\u2019onboarding<\/span>. Vous pouvez utiliser cet \u00e9cran pour expliquer comment faire en sorte d\u2019avoir du contenu sur cette partie.<\/p>\n Nous utilisons cette technique sur la partie \u00ab saved search<\/span> \u00bb de notre interface. Il est possible de faire des recherches multicrit\u00e8res tr\u00e8s complexes dans notre interface. Pour ne pas avoir \u00e0 remettre tous les crit\u00e8res nous offrons la possibilit\u00e9 de sauvegarder une recherche sur le Dashboard<\/span>. Mais, quand on arrive pour la 1e fois sur l\u2019\u00e9cran des recherches sauv\u00e9es, il est vide. Nous utilisons cet \u00e9cran comme opportunit\u00e9 d\u2019onboarding<\/span> pour expliquer comment sauver une recherche et informer de l\u2019existence de cette fonctionnalit\u00e9.<\/p>\n Parfois, le contenu manquant se situe au niveau des composants.<\/strong><\/p>\n Par exemple, sur un site de recettes de cuisine, que se passe-t-il s\u2019il manque l\u2019image de l\u2019aper\u00e7u de recettes?<\/p>\n Quelle que soit la d\u00e9cision prise en mati\u00e8re de design, l’\u00e9quipe de d\u00e9veloppement doit g\u00e9n\u00e9ralement en \u00eatre inform\u00e9e afin d’anticiper et de construire un HTML\/CSS flexible. Et m\u00eame parfois anticiper la construction de l’API dans certains cas.<\/p>\n Que se passe-t-il si certains contenus n’ont pas (encore) de valeur<\/strong> ?<\/p>\n Dans notre exemple d’aper\u00e7u de recette de cuisine o\u00f9 on affiche un nombre d\u2019\u00e9toiles en fonction de la note, qu\u2019est-ce qu\u2019on fait s\u2019il n\u2019y a pas encore de note ?<\/p>\n Je n\u2019ai pas forc\u00e9ment la meilleure solution en t\u00eate, c\u2019est un de ces cas o\u00f9 il va falloir it\u00e9rer et tester. Mais \u00e7a reste un cas \u00e0 pr\u00e9voir en termes de design.<\/p>\n En g\u00e9n\u00e9ral quand je design les \u00e9crans vides de pages, je mets donc \u00e0 jours mon sch\u00e9mas avec \u00e9galement ces \u00e9tats \u201cvides\u201d<\/p>\n Mais au final, je n’ai pas forc\u00e9ment besoin de designer<\/strong> chaque cas. Le but est surtout de d\u00e9cider<\/strong> de ce qui va se passer et le communiquer cela \u00e0 \/ avec l’\u00e9quipe de d\u00e9veloppement. <\/strong>Ensuite, c’est \u00e0 elleux de coder ces composants. Niveau documentation, j’essaie g\u00e9n\u00e9ralement de documenter la fa\u00e7on<\/strong> dont les composants sont cens\u00e9s fonctionner \u00e0 un niveau g\u00e9n\u00e9rique<\/strong>.<\/p>\n Comme beaucoup de ces composants de tuiles de contenus, je n’ai g\u00e9n\u00e9ralement pas forc\u00e9ment le temps<\/strong> de designer chacun<\/strong> d’entre eux pour tous les \u00e9tats, d’autant plus que les \u00e9tats de chargement et d’erreur sont les m\u00eames. <\/strong>La seule diff\u00e9rence est le message.<\/p>\n C’est ce que j’ai fait :<\/p>\n Enfin, nous avons mis en place une checklist <\/strong>pour s\u2019assurer de ne pas oublier ces diff\u00e9rents \u00e9tats dans cette documentation.<\/p>\n Bon, maintenant nous avons notre contenu. Mais, et si nous avions plus de contenu que le cas id\u00e9al que nous avons con\u00e7u ? Est-ce que votre design est capable de s\u2019adapter. En anglais, c\u2019est la blague de \u00ab yes, but does it scale ? \u00bb<\/p>\n Au niveau des pages, le cas beaucoup de contenu, en particulier les listes de pages, peut \u00eatre trait\u00e9 de 4 mani\u00e8res diff\u00e9rentes :<\/p>\n Quelle que soit la solution choisie, assurez-vous \u00e9galement que si la personne a ouvert un \u00e9l\u00e9ment et retourne \u00e0 la liste, elle arrive au m\u00eame endroit dans la liste et non en haut.<\/strong> Il n\u2019y a rien de pire que d\u2019arriver au produit 340\/600, l\u2019ouvrir, et revenir au produit num\u00e9ro 1 quand on revient en arri\u00e8re dans le navigateur. \u00c7a fait d\u2019ailleurs partie des bonnes pratiques de Google en termes de pagination.<\/p>\n On doit aussi parfois g\u00e9rer la densit\u00e9 du contenu au niveau des composants<\/strong>.<\/p>\n Par exemple :<\/p>\n Techniquement, il n’y a rien de complexe ici. Mais encore une fois, c\u2019est le type de d\u00e9cisions de design \u00e0 prendre et communiquer <\/strong>\u00e0 l’\u00e9quipe de d\u00e9veloppement. Encore une fois ce sont des d\u00e9cisions de design \u00e0 prendre. Tout \u00e7a peut aussi devenir tr\u00e8s vite p\u00e9nible si vous utilisez des squelettes de chargement, si tous les contenus n\u2019ont pas la m\u00eame hauteur, difficile de pr\u00e9voir un squelette g\u00e9n\u00e9rique.<\/p>\n Et oui, j\u2019utilise toujours Sketch. Vous pouvez vous moquer de l\u2019outil autant que vous voulez sur LinkedIn (je l\u2019ai vu plusieurs fois), mais je travaille pour une banque qui n\u2019aime pas trop les outils cloud. D\u2019ailleurs si vous voulez en savoir plus sur mon processus avec des outils 100% locaux et self hosted, j\u2019ai fait un article sur le sujet : The Pragmatic Designer: Local and Self Hosted Design Tools<\/a><\/p>\n Voici quelques conseils pour vous aider \u00e0 designer ces cas:<\/p>\n La page s’est donc charg\u00e9e. Houraaa. Mais on peut aller un cran plus loin, et commencer \u00e0 parler d\u2019exp\u00e9rience continue et perception de la performance<\/strong><\/p>\n Depuis l\u2019an dernier, tout le monde parle de ces Core Web Vitals<\/span><\/a>. J’ai entendu et vu \u00e9crit que \u00ab en 2021 l\u2019exp\u00e9rience utilisateur sera un crit\u00e8re de ranking<\/span> pour Google \u00bb. Et \u00e7a m\u2019a h\u00e9riss\u00e9 le poil \u00e0 chaque fois, parce que c\u2019est au mieux une TRES grosse approximation, au pire un bon gros titre clickbait d\u2019article sur des blogs de techos qui veulent de la visite. La v\u00e9rit\u00e9 de la vraie vie est un peu plus compliqu\u00e9e que \u00e7a.<\/p>\n Tout d’abord, Google appliquait d\u00e9j\u00e0 des p\u00e9nalit\u00e9s pour des choses qui peuvent nuire \u00e0 l’exp\u00e9rience utilisateur bien avant 2021<\/strong>. Je pense par exemple comme la p\u00e9nalit\u00e9 sur les interstices qui a \u00e9t\u00e9 lanc\u00e9e en 2015<\/a>. Google n\u2019a pas attendu cette ann\u00e9e pour avoir de type de crit\u00e8res. Si vous voulez en savoir plus, Myriam Jessier, (mon experte SEO et SXO pr\u00e9f\u00e9r\u00e9e) a un article int\u00e9ressant sur le CLS<\/a>.<\/p>\n Ensuite, mesurer l’exp\u00e9rience de l’utilisateur est plus complexe que \u00e7a et va bien au-del\u00e0 de ces 3 mesures<\/strong> qui sont, encore une fois. Je pourrais faire un article qui fait la taille de celui-l\u00e0 juste sur diff\u00e9rents crit\u00e8res de la mesure de l\u2019exp\u00e9rience utilisateur, mais ce n\u2019est pas le propos. Je vous laisse donc vous renseigner par vous-m\u00eame. Si vous ne savez pas o\u00f9 trouver de l\u2019info fiable sur le domaine de la recherche utilisateur je vous renvoie \u00e0 80+ UX blogs (with RSS feed) to follow<\/a> et 15 + blogs francophone sur l\u2019UX Design (avec flux RSS)<\/a><\/p>\n Ce qu\u2019il faut comprendre:<\/p>\n Vos utilisatrices et utilisateurs ne surveillent pas la vitesse de votre page ou votre score LPC. La performance est quelque chose que l\u2019on per\u00e7oit<\/strong>. Il est donc tout aussi important de cr\u00e9er une exp\u00e9rience continue et per\u00e7ue comme rapide. Voici quelques m\u00e9thodes et id\u00e9es pour vous aider dans ce sens.<\/p>\n L’un des param\u00e8tres des vitals est le FID (First Input Delay<\/span>) et mesure l’interactivit\u00e9<\/strong>.<\/p>\n La plupart du temps, nous nous arr\u00eatons \u00e0 \u00ab l’\u00e9tat par d\u00e9faut final sur l’\u00e9cran \u00bb et oublions l’interactivit\u00e9 comme le survol, la navigation au clavier, au touch<\/span>, etc, etc. Pourtant, \u00e7a fait partie du travail de designer de les imaginer et documenter.<\/p>\n Je communique g\u00e9n\u00e9ralement les \u00e9tats interactifs dans le design system<\/span> (afin que les d\u00e9veloppeurs n’aient pas \u00e0 passer par 40 maquettes pour trouver o\u00f9 je cache l’interaction)<\/p>\n J\u2019essaie \u00e9galement de proposer les diff\u00e9rentes interactions des composants<\/strong> \u00e0 l\u2019aide de sch\u00e9mas d\u2019interactions qui lisent comment le composant va se comporter \u00e0 diff\u00e9rents \u00e9tats, ce qu\u2019il se passe au clique mais \u00e9galement la navigation au clavier.<\/p>\n Et nous pourrions aller plus loin.<\/p>\n Que diriez-vous d’imaginer des exp\u00e9riences avec un support hors ligne <\/strong>m\u00eame pour le web ?<\/p>\n Par exemple<\/p>\n Nous pourrions \u00e9galement stocker les donn\u00e9es des formulaires dans le cache<\/strong>. Comme \u00e7a, si la personne soumet le formulaire mais qu\u2019il y a une erreur de connexion, elle n\u2019a pas perdu les donn\u00e9es<\/strong> et n\u2019as pas besoin de les re-remplir. D\u2019ailleurs Geoffrey Crofte a un petit script pour vous aider qui s\u2019appelle \u00ab form-saver <\/a>\u00bb<\/p>\n Un autre moyen courant de g\u00e9rer la perte de connexion sur les applications natives est d’avoir de la synchronisation en t\u00e2che de fond. <\/strong>Et on peut maintenant (bient\u00f4t) le faire pour des sites web aussi (gr\u00e2ce \u00e0 Background Sync API<\/a>).<\/p>\n Cela apport de nouveaux challenges<\/strong> et nouveaux \u00e9tats \u00e0 designer<\/strong>:<\/p>\n En outre, vous allez sans doute pr\u00e9voir une notification<\/strong> une fois que l’\u00e9l\u00e9ment a \u00e9t\u00e9 synchronis\u00e9 en arri\u00e8re-plan<\/strong> si la personne a quitt\u00e9 l\u2019App ou le site. Il va aussi falloir en designer et r\u00e9diger le contenu ;)<\/p>\n Une autre id\u00e9e int\u00e9ressante serait d’adapter l’interface aux conditions du r\u00e9seau et de bande passante. <\/strong>Nous ne sommes pas tous dans le monde sur un r\u00e9seau 4G (ou 5G) super rapide. Dans les applications natives (mais aussi sur le web), YouTube (et Netflix) changent la qualit\u00e9 de la vid\u00e9o en fonction de la bande passante. \u00c7a explique pourquoi parfois d\u2019un coup votre vid\u00e9o est toute pixelis\u00e9e et 3 secondes apr\u00e8s c\u2019est revenu \u00e0 la normale. La qualit\u00e9 a \u00e9t\u00e9 r\u00e9duite \u00e0 cause sans doute d\u2019une mini baisse de d\u00e9bit.<\/p>\n On peut imaginer des cas d’utilisation int\u00e9ressants pour cela :<\/p>\n Les possibilit\u00e9s sont assez int\u00e9ressantes<\/strong>. Mais l\u00e0 encore, toutes ces choses doivent \u00eatre pr\u00e9par\u00e9es et faire partie de nos parcours utilisateurs.<\/strong><\/p>\n Non je ne vais pas vous parler d\u2019\u00e9cologie ici. Mais qu’est-ce qui est pire que de cliquer sur la mauvaise ic\u00f4ne parce qu\u2019il n\u2019y a pas de label, puis la page se charge, ce n’est pas la bonne page. On doit retourner la page pr\u00e9c\u00e9dente, retrouver le bon chemin ?<\/p>\n Ne faites pas perdre leur temps et leurs ressources (cognitives et navigateur) \u00e0 vos utilisatrices et utilisateurs !<\/strong><\/p>\n Voici comment \u00e9viter cela:<\/p>\nDesigner ce qu\u2019il se passe durant le chargement.<\/h2>\n
\n
Identifier les contraintes techniques<\/h3>\n
D\u00e9cider ensemble d\u2019une strat\u00e9gie de chargement<\/h3>\n

\n
\n

Testez, testez, testez.<\/h3>\n
Designer les cas d\u2019erreur.<\/h2>\n
\n
Erreurs au niveau de la page<\/h3>\n
Erreur au niveau du composant<\/h3>\n
Messages d\u2019erreurs : les bonnes pratiques<\/h3>\n
\n
\n
Documentation des messages d\u2019erreur<\/h3>\n

\n
Designer pour des contenus manquants<\/h2>\n
Pas de r\u00e9sultats et \u00e9crans vides<\/h3>\n

Contenu vide g\u00e9n\u00e9r\u00e9 par les utilisatrices<\/h3>\n

Du contenu manquant dans un composant<\/h3>\n
\n

\n

Communiquer les \u00e9tats avec les \u00e9quipes de d\u00e9veloppement<\/h3>\n

\n
Designer pour \u00ab plus \u00bb de contenu<\/h2>\n

\n
\n

\n

Quelques conseils pour la densit\u00e9 de contenus<\/h3>\n
\n
Designer une exp\u00e9rience ininterrompue per\u00e7ue comme performante<\/h2>\n
Google, le mythe de la mesure de l\u2019UX et des Core Web Vitals<\/span><\/h3>\n

\n
Designer les \u00e9tats d\u2019interactivit\u00e9<\/h3>\n

Designer pour le support hors ligne<\/h3>\n
\n

Designer pour la synchronisation en t\u00e2che de fond<\/h3>\n

\n
Designer pour diff\u00e9rentes conditions de bande passante<\/h3>\n

\n
Ne pas gaspiller les ressources techniques et cognitives.<\/h3>\n

\n