RGESN, ce que doivent faire les designers

1. Recherche

La recherche utilisateur fait intrinsèquement partie de l’écoconception comme le prouve l’intégration de plusieurs critères sur ce sujet. Selon les organisations et les sujets, ce terme peut recouvrir la recherche primaire, la phase de « Discovery », un début de Design Sprint, un sprint de recherche, une analyse de l’existant, une analyse de données d’audience…

Identifier l'utilité et la nécessité du service

La recherche utilisateur va dans un premier temps pouvoir venir nourrir la nécessité de prouver l'utilité du service d’un point de vue environnemental et/ou social. Les designers ayant effectué en amont de la recherche utilisateur peuvent ici nourrir l’argumentaire (ex : lutte contre la fracture numérique, accès à l’éducation, etc.) en détaillant les besoins réels justifiant la création du service et la nécessité des fonctionnalités. Les besoins utilisateurs pourront être intégrés dans les Objectifs de Développement Durable. [Critère 1.1]

Pour vous aider à savoir si votre service doit être développé, voir l’arbre de décision.

Nous rappelons que la création d’un service numérique a toujours un impact environnemental négatif, même éco-conçu, et que l’évaluation d’une valeur ajoutée significative pour la société est un pré-requis absolu à son développement. Le service créé doit prouver son utilité par rapport à des solutions analogiques alternatives ou numériques existantes. [Critère 1.2] Les benchmarks et veilles concurrentielles que les Product designers effectuent généralement pourront également alimenter ici l’analyse.

Définir les besoins réels de ses utilisateurs

• Prioriser ses cibles utilisatrices entre primaires et secondaires. [Critère 1.2]
• S’il y a un existant, effectuer : [Critère 1.2]
  • une analyse des données de suivi d’audience : repérer ce qui n’est jamais utilisé / visité, les allers-retours, les mots les plus cherchés du moteur de recherche…
  • une étude UX de l’expérience actuelle : identifier les stratégies de contournement développées, les difficultés rencontrées sur les parcours prioritaires, les principaux besoins non répondus…
  • une analyse des matériels utilisés : appareil, résolution, version du navigateur et du système d’exploitation… [en lien au Critère 2.1]
• Réaliser des entretiens utilisateurs, des sondages ou observations auprès des utilisateurs pour relever leurs besoins. Penser à inclure des utilisateurs éloignés du numérique et en situation de handicap.
• Créer des personas définissant leurs usages, leurs besoins, leurs comportements. NB : vous pouvez ajouter à leur profil les matériels utilisés, par exemple un persona pourrait être éloigné du numérique avec un smartphone de plus de 7 ans ou une connexion ADSL. [en lien avec les Critères 2.1 et 2.3]
• Identifier les durées requises de conservation des contenus pour les utilisateurs : brouillons, posts, historique... [Critère 5.8]

Définir le produit cible

Définir les unités fonctionnelles et les fonctionnalités principales du service (nécessaire ultérieurement pour le Critère 4.3) : jobs-to-be-done, parcours principaux, fonctionnalités… Voir Unité fonctionnelle. A définir conjointement avec les PM et PO (alimentation du backlog et rédaction des user stories). 

En fonction des contextes d’usage et des profils matériels identifiés des utilisateurs, définir un poids maximum par écran. Le service doit être en effet utilisable en connexion bas débit. Par conséquent on pourra déterminer le poids maximum en se posant la question : en connexion dégradée (3G moyenne par exemple), en combien de secondes maximum ma page doit-elle charger ? (voir Guide) Pour rappel, près d'1/3 des connexions internet à domicile sont encore en ADSL en 2023 (source : Baromètre du numérique 2023). Selon la taille de l’équipe, le poids maximum peut être décidé conjointement avec d’autres métiers. [Critère 6.1]

De la même façon, il peut être intéressant que le Design soit impliqué dans le choix de la limite de requêtes par écran. En effet, cela va impacter le design car tout ce que le designer va venir ajouter sur sa maquette va impacter ce nombre : variations de police, images, plugins… L’impliquer dans cette décision permet de l’acculturer sur ce point technique et ses implications concrètes. [Critère 6.1]

Évaluer et mesurer

Dans le cadre d’un service existant, mesurer les indicateurs techniques des parcours identifiés : nombre de requêtes, poids des ressources téléchargées… Cela permettra de se positionner suite aux évolutions ou refonte à venir. Ce critère est une responsabilité qui peut incomber au référent écoconception ou encore aux profils Tech. [Critères 4.3, 6.1]

3. Prototypage

Généralement itératif, le prototypage peut aller du zoning à l’interface haute-fidélité cliquable en passant par l’étape du wireframe.

Bonnes pratiques globales

Prototyper ses écrans en mobile-first de préférence afin de s’assurer que le service soit responsive. Le service doit être intégralement affiché pour des écrans de 1200 px de large minimum. Il faut anticiper une ligne de flottaison à 720 px de haut maximum et donc s’assurer que le défilement vertical est possible au-delà ou que toutes les fonctionnalités de base soient accessibles au-dessus. [Critère 2.5]

Optimiser le parcours de navigation pour chaque fonctionnalité principale. Éliminer les fonctionnalités non essentielles. Voir le chapitre dédié dans le Guide d'écoconceptiond de services numériques [Critère 4.3]

Informer l’utilisateur sur l’impact environnemental de ses usages et lui permettre de réduire son empreinte par la mise à disposition d’un mode d’affichage ou d’usage « sobres » (ex : résolution plus faible des vidéos, affichage des images au clic, actualisation de la boîte de réception espacée…). [Critère 4.15]

Bannir les procédés manipulatoires ou darks patterns(compte à rebours sur une offre, option pré-cochée, parcours labyrinthiques…). Vous pouvez auditer vos wireframes pour vérifier que vous n’avez mis aucun dark pattern. Voir le Guide Concevoir sans Dark Patterns [Critère 4.14]

Sur les interfaces

Animations, vidéos, sons

• Bannir les fonds vidéo et/ou audio. [Critère 4.1]
• Privilégier le texte ou l’image au lieu de l’animation, la vidéo ou le son lorsque cela est possible. Choisir la solution au besoin utilisateur la plus sobre possible (texte plutôt qu’image, animation plutôt que vidéo par exemple). [Critère 4.7]
• N’utiliser que des vidéos, audios et animations porteurs d’information (bannir leur utilisation décorative). Ainsi leur utilisation n’est autorisée que si leur utilisation est requise par les fonctions critiques du service. [Critère 4.6] 
• En cas d’animation, vidéo ou son, désactiver la lecture automatique par défaut. Si cela n’est vraiment pas possible, permettre à l’utilisateur d’annuler la lecture automatique facilement. Éviter les carrousels automatiques, les parallaxes, les gifs, les boutons qui bougent ou clignotent, et autres animations décoratives non contrôlables… [Critère 4.1]
• Proposer un mode « écoute seule » pour les vidéos. [Critère 5.5]

Interactions

• Bannir le défilement ou scroll infini en privilégiant du chargement progressif (bouton « voir plus » par exemple). [Critère 4.2] 
• Indiquer à l’utilisateur lorsqu’une fonctionnalité à des impacts environnementaux importants (ex : visionnage d’une vidéo en haute définition, export d’un grand volume de données, recherche sur une grande base…). Si des équivalences en impacts environnementaux sont citées par exemple, citer les sources et la méthodologie de calcul. [Critère 4.12]
• Limiter le recours aux notifications et permettre à l’utilisateur de les contrôler : de les désactiver de façon simple et rapide, de choisir leur fréquence de réception... Elles doivent être dans l’intérêt de l’utilisateur. Se fixer des quantités et fréquences maximales de notifications (ex : 5 par jour maximum) et les suivre. [Critère 4.13] Voir la section Interactions du Guide d'écoconception de services numériques.
• Informer l’utilisateur lorsqu’un traitement est en cours en arrière-plan : sinon il risque de relancer l’action et de générer des requêtes superflues. Rendre indisponible l'action qui génère le traitement (par exemple un bouton de soumission de formulaire) et informer l'utilisateur que le traitement est en cours, éventuellement en affichant une durée approximative de traitement.

Documents

• Informer l’utilisateur sur le format et poids de fichier avant transfert ou téléchargement. Limiter le poids des fichiers uploadés : par exemple à 300 Mo une photo mise en ligne. [Critère 4.11]
• Proposer un format de fichier adapté à son contenu et au contexte d’utilisation : privilégier les formats les plus légers, éviter par exemple un pdf vertical si le document sera principalement consulté sur écran d’ordinateur en format paysage, un pdf HD destiné à l’impression s’il sera consulté principalement en ligne (résolution 72 dpi recommandée)... [Critère 5.7]

Polices

• Privilégier les polices nativement disponibles dans le système d’exploitation (polices système). [Critère 4.8]
• Limiter le nombre de polices à 4 variantes maximum au total ou 400 Ko. [Critère 4.8]Réduire la taille des polices téléchargées (supprimer les glyphes non utilisés, compresser les fichiers…). NB : une police bien compressée en WOFF2 ne pèse que 30 Ko environ. [Critère 4.8]

Plugins, widgets et services tiers

Choisir des composants légers et éco-conçus pour répondre au besoin et éviter au maximum de recourir à des service-tiers (carte interactive, lecteur vidéo, plugins de réseaux sociaux, captcha…). Prototyper des solutions natives ou éco-conçues à la place. Par exemple :

• si l’incrustation d’une vidéo est nécessaire, privilégier un lecteur vidéo HTML5 plutôt que le plugin Youtube ; 
• remplacer les plugins des réseaux sociaux par des icones cliquables ;
• éviter les captchas ;
• pour un moteur de recherche, prototyper la génération de résultats au lancement de la recherche par l’utilisateur plutôt qu’une mise à jour automatique des résultats à chaque filtre ajouté.

Ces choix de conception nécessitant une certaine connaissance technique et en écoconception : échanger avec les développeurs ou le référent écoconception sur la meilleure façon de répondre au besoin pour valider ce critère. Si cela n’est pas possible, choisir les services les plus éco-conçus possibles. [Critères 2.9, 2.10]

Permettre à l’utilisateur de décider de l’activation d’un service tiers non nécessaire et donc ne charger que ce à quoi il a explicitement consenti (ex : lecteurs vidéo collectant les cookies désactivés en cas de refus de collecte des données personnelles). [Critère 4.4]

Formulaires

• Limiter les requêtes serveur lors de la saisie utilisateur : éviter l’auto-complétion, les résultats suggérés… [Critère 4.9]
• Si sa mise en place est justifiée, attendre d'avoir 3 caractères et 500 ms après chaque saisie avant de lancer une requête réseau. [Critère 4.9]
• Permettre d’activer et désactiver l’auto-complétion. [Critère 4.9]Informer l’utilisateur du format de saisie attendu avant sa validation et indiquer les erreurs de saisie avant soumission du formulaire. [Critère 4.10]

Revue design

Faire une revue de conception avant de développer : présenter les interfaces prototypées aux développeurs et réfléchir aux choix de conception et d'architecture avec toute l’équipe, en ayant pour un des objectifs la minimisation des impacts environnementaux. Choisir la solution répondant aux besoins minimisant le plus les impacts environnementaux. [Critère 2.6]

5. Tester et maintenir

Selon la taille des services, les designers peuvent être amenés à recetter et tester le service.

Tester en pré-prod

S’assurer que le service est utilisable sur une connexion bas débit (3G en mobilité et 512 Kbs en fixe). Les designers peuvent facilement effectuer ce test qui recoupe des enjeux environnementaux, sociaux et d’expérience utilisateur. [Critère 2.3]

S’assurer que le service est bien responsive (par exemple avec les outils de développement du navigateur). Tester notamment sur des résolutions de vieux smartphones (320 px de large). [Critère 2.5]

Remplir les formulaires avec des données erronées et s’assurer que les messages d’erreur soient explicites. [Critère 4.10]

Tester, y compris périodiquement, la lecture des vidéos sur différents terminaux afin de vérifier que ces vidéos en mode « qualité standard » et « sobriété énergétique » ont un format adapté à ces terminaux. [Critère 5.3]

Effectuer des tests utilisateurs avec des personnes éloignées du numérique (appareils anciens, connexion bas-débit, navigateurs non mis à jour…) et s’assurer qu’elles parviennent à finir leur parcours. [Critères 2.2, 2.3, 2.4]

Amélioration continue

Ne collecter que les données de navigation nécessaires à l’analyse de l’expérience utilisateur. Quoique certains outils soient extrêmement puissants et instructifs en matière de suivi, ils collectent potentiellement automatiquement plus de données que nécessaire (ex : enregistrements complets de parcours que l’on peut rejouer). Il incombera notamment aux CDO ou Lead Designers d’estimer quels outils sont pertinents ou de les paramétrer pour ne collecter que le minimum requis. Dans certains cas, quelques simples cookies peuvent permettre de se passer d’un outil de suivi d’audience. [Critères 1.5, 2.10]

Mesurer le temps passé par l’utilisateur pour effectuer une action et le minimiser le plus possible. Identifier les fonctionnalités utilisées ou non. Améliorer en continu les parcours utilisateurs correspondant aux unités fonctionnelles du service par de la recherche utilisateur et l’analyse du suivi d’audience. Poursuivre la recherche utilisateur : tri de carte, sondage, interviews, enquêtes utilisateurs, tests-U, etc. [Critère 4.3]

Identifier les pages / fonctionnalités peu utilisées et étudier leur potentiel décommissionnement. Grâce aux outils d’analyse de la navigation et la connaissance des besoins utilisateurs, identifier si des parties du service peuvent être arrêtées. [Critère 2.7]

Réaliser des revues régulières d’écoconception : audits de performance, auto-évaluation RGESN, identification des points de friction dans le parcours utilisateur... La régularité dépend du service mais devra survenir au moins à chaque « changement significatif » du service. Le designer peut être appelé à contribuer sur ce critère. [Critère 1.4]