5.0 Introduction à la partie 5 : la conception UI/UX
Cette partie parle de là où le logiciel rencontre les personnes qui l’utilisent. Cela couvre beaucoup de terrain : la recherche qui révèle ce dont les utilisateurs ont besoin, l’interface et le système de conception qui le présentent, les mots qui guident l’action, l’accessibilité et le support linguistique qui le rendent utilisable par tout le monde, et l’ingénierie frontend qui le livre dans la réalité désordonnée des vrais navigateurs et appareils. Il est tentant de traiter tout cela comme une décoration que vous appliquez à la fin. Résistez à cela s’il vous plaît. C’est là que tout le travail en amont atteint l’utilisateur ou s’effondre, et cela se décide bien avant que le dernier écran ne soit poli.
Pour les grandes équipes, la conception de produit est vraiment un problème de coordination. Quand des dizaines d’escouades livrent dans un seul produit partagé, des décisions indépendantes s’empilent en un désordre : flux dupliqués, terminologie contradictoire, composants incohérents, et un pipeline linguistique que personne ne possède. La correction dans chaque chapitre ici a la même forme. Transformez les décisions ponctuelles en actifs partagés et gouvernés, tels que des personas, un système de conception, une stratégie de contenu, un cadre d’internationalisation (i18n), des bibliothèques de composants, et des budgets de performance, pour que de nombreuses équipes travaillant séparément s’additionnent toujours en une seule expérience cohérente.
L’entreprise et l’administration publique élèvent encore les enjeux. Le logiciel d’entreprise a souvent des utilisateurs captifs, et ils paient pour une mauvaise conception en formation, erreurs, et charge de support plutôt qu’en partant. Les services gouvernementaux atteignent le public entier (y compris des personnes en crise, sur d’anciens appareils, avec une faible confiance numérique, ou sans fournisseur alternatif), donc la qualité de conception devient une question d’équité et de confiance civique. Ici, l’accessibilité n’est pas un plus agréable mais un mandat légal : les organismes publics sont tenus par la loi de construire du logiciel que les personnes handicapées peuvent utiliser, et les obligations de langage clair et d’accès linguistique portent fréquemment aussi la force de la loi.
Chapitres de cette partie
5.1 Fondements UX. Les pratiques de recherche, de modélisation d’utilisateur, et de pensée design qui permettent à une organisation de prendre des décisions de produit fondées sur des preuves au lieu de deviner, et donnent à chaque équipe la même carte de l’utilisateur.
5.2 Conception UI et systèmes de conception. L’art de façonner ce que les gens voient et touchent, et le système partagé et gouverné de jetons, composants, et motifs qui garde des milliers d’écrans à travers de nombreuses équipes cohérents.
5.3 Accessibilité. Construire du logiciel que les personnes handicapées peuvent percevoir, exploiter, comprendre, et utiliser, traité simultanément comme un devoir légal, un devoir éthique, et simplement une bonne conception.
5.4 Conception de contenu et de communication. Façonner les mots, messages, et communications qu’un produit utilise pour aider les gens à agir, en langage clair et voix cohérente, parce que les mots sont interface.
5.5 Internationalisation et localisation. L’architecture qui permet au logiciel de s’adapter à toute langue et région, et le flux de travail qui le traduit et l’adapte culturellement pour chaque locale.
5.6 Ingénierie frontend. Construire la couche orientée client pour un environnement que vous ne contrôlez pas, avec attention à la longévité du cadriciel, la stratégie de rendu, la performance, et la résilience.
5.7 Développement d’applications mobiles. Construire pour les appareils mobiles, couvrant les approches natives, multiplateformes, et web progressives ; les directives de conception de plateforme ; les contraintes hors ligne, de batterie, et de fragmentation ; la distribution en magasin d’applications ; et la sécurité et l’accessibilité mobiles.
5.8 Recherche de conception et test d’utilisabilité. Réduire le risque de construire la mauvaise chose par la recherche générative et évaluative, la bonne méthode pour chaque question, le test d’utilisabilité bien fait, le recrutement représentatif, et la synthèse qui change réellement les décisions.
5.9 Conception de service. Concevoir le service entier qu’une personne vit à travers les canaux et dans le temps, à l’avant-scène et en coulisse, en utilisant des schémas de service et des cartes de parcours et en alignant l’organisation derrière le service, pas seulement un seul écran.
5.10 Conception de visualisation de données. Choisir le bon graphique pour la question et encoder les données honnêtement, en appliquant l’excellence graphique, des palettes accessibles et sûres pour le daltonisme, et une annotation claire, pour qu’un graphique informe une décision au lieu de la tromper.
Comment ces chapitres s’articulent
Ces chapitres forment un fil conducteur unique de la compréhension à la livraison. Les fondements UX (5.1) établissent qui est l’utilisateur et quelle tâche il essaie d’accomplir. L’UI et les systèmes de conception (5.2) donnent à cette compréhension une forme visuelle cohérente. La conception de contenu (5.4) fournit les mots qui la portent. L’ingénierie frontend (5.6) livre le résultat. L’accessibilité (5.3) et l’internationalisation (5.5) ne sont pas des étapes séparées mais des qualités tissées à travers toutes les autres : une expérience accessible et traduisible est conçue dans les composants partagés, les motifs de contenu, et le code dès le début, jamais boulonnée plus tard. Le chapitre 5.3 en particulier s’appuie sur le chapitre 5.2 pour résoudre l’accessibilité une fois dans chaque composant, et sur le chapitre 5.6 pour la préserver dans un balisage sémantique et fondé sur les normes.
Cette partie s’étend aussi à travers le guide. Le motif « actifs plutôt que ponctuels » ici reflète la pensée de plateforme partagée du chapitre 8.4 (ingénierie de plateforme et expérience développeur), et les valeurs et façons de travailler des chapitres 1.1 et 1.4 fixent les conditions organisationnelles qui rendent la cohérence de conception possible du tout. Les contrôles d’accessibilité, de régression visuelle, et de budget de performance appartiennent aux pipelines de livraison du chapitre 8.1 (CI/CD et livraison), pour que la qualité soit imposée à chaque changement plutôt qu’auditée juste avant le lancement. Et la surveillance d’utilisateur réel (données de performance collectées depuis les appareils et réseaux des vrais utilisateurs) dont dépend la performance frontend se connecte directement aux pratiques d’observabilité du chapitre 9.2. Bien fait, le travail ici est ce qui rend les systèmes décrits ailleurs réellement utilisables par les personnes qu’ils sont censés servir.