Primitive
Valeurs brutes
La palette de valeurs de base, sans présumer de l’endroit où elles seront utilisées.
ÉTUDE DE CAS
L’Identité Numérique :préserver la qualité UI à mesure que le produit grandit
- RÔLE
- UI Designer
- ANNÉE
- 2022–2025
- ÉCHELLE
- Plus de 9 millionsd’Identités Numériques créées
- ÉQUIPE
- 4 UX Designers · 2 UI Designers · 4 Product Managers · Développeurs
LE PROJET
L’Identité Numérique La Poste est un service d’identité numérique sécurisé qui permet de prouver son identité et de s’authentifier auprès de services en ligne, sans avoir à créer de nouveaux comptes ou à transmettre à nouveau ses documents d’identité.
Grâce à FranceConnect et FranceConnect+, elle peut être utilisée aussi bien pour des démarches du quotidien que pour des services en ligne plus sensibles (impôts, CAF, France Travail, Mon Compte Formation) tout en offrant une protection renforcée contre la fraude à l’identité. Aujourd’hui, L’Identité Numérique La Poste a été adoptée par plus de 9 millions de personnes et donne accès à plus de 1 800 services.
Lorsque j’ai rejoint le projet, le produit était déjà en production et connaissait une forte montée en charge. En parallèle, différentes parties de l’expérience évoluaient simultanément au sein de plusieurs squads Product.
J’ai rejoint le projet comme l’un des deux UI Designers d’une équipe Design comprenant également quatre UX Designers et une cheffe de projet. Nous travaillions aux côtés de quatre Product Managers et des équipes de développement. Alors que les UX Designers étaient répartis sur différentes briques du produit, les deux UI Designers intervenaient transversalement sur l’ensemble de l’expérience.
Notre enjeu n’était donc pas seulement de concevoir des interfaces individuellement, mais de préserver un niveau de qualité UI cohérent à mesure que le produit, le système et le nombre de contributeurs grandissaient.
LA PROBLÉMATIQUE
Comment maintenir une expérience cohérente à mesure qu’un produit grandit et évolue au sein de plusieurs squads ?
01Cohérence UI
Maintenir la cohérence entre plusieurs squads
En tant que l’un des deux UI Designers, j’intervenais transversalement sur l’ensemble de l’expérience, tandis que les UX Designers étaient répartis dans différentes squads, chacune concentrée sur une partie spécifique du produit avec son Product Manager.
Selon les sujets, je pouvais intervenir une fois l’UX déjà définie ou plus tôt dans le processus afin de challenger et affiner la solution avec l’UX Designer avant de passer à l’UI.
Passer constamment d’un parcours à un autre nous donnait une vision globale du produit, mais faisait aussi apparaître un risque récurrent : à mesure que chaque squad résolvait ses problèmes de manière indépendante, des décisions locales pouvaient progressivement fragmenter l’expérience globale.
Notre rôle dépassait donc la conception d’écrans. Nous étions également responsables de maintenir la cohérence UI, de faire évoluer le Design System et de suivre la qualité jusqu’au delivery et à l’implémentation.
02Design System
Faire évoluer le Design System pour renforcer la cohérence
Le Design System existait déjà lorsque j’ai rejoint le projet. Avec l’autre UI Designer, nous étions responsables de sa maintenance et de son évolution à mesure que de nouveaux besoins apparaissaient dans les différentes squads.
Avec la croissance du produit et l’apparition de nouveaux besoins, le système existant devenait de plus en plus difficile à faire évoluer de manière cohérente. Nous avons donc décidé de le faire évoluer vers une V2 : revoir les composants existants, améliorer leur construction dans Figma, créer les patterns manquants et nettoyer une bibliothèque qui s’était développée progressivement avec le produit.
Nous avons repris les composants existants, amélioré leur construction dans Figma, créé ceux qui manquaient et corrigé les incohérences accumulées au fil de l’évolution du produit.
Les évolutions des composants étaient testées dans de vrais écrans avant d’être intégrées au système. Lorsque nécessaire, nous impliquions également d’autres designers et les développeurs afin de vérifier que les règles fonctionnaient aussi bien dans l’interface que dans leur implémentation.
Ce travail dépassait également les composants pour couvrir l’ensemble de la bibliothèque d’assets. Nous avons nettoyé et structuré les éléments visuels partagés (illustrations, logos et iconographie) en réorganisant notamment les icônes en familles line, plain et contextual, et en améliorant leur organisation ainsi que leur nomenclature.
03Variables Figma
Passer des Styles Figma aux Variables
Le Design System reposait encore principalement sur des Figma Styles, avec certaines valeurs maintenues manuellement pour les trois tailles mobiles que nous utilisions. Une modification pouvait donc nécessiter plusieurs mises à jour et créer des incohérences entre les différentes variantes.
Lorsque Figma a introduit les Variables, j’ai proposé de profiter de cette évolution pour repenser l’architecture du système plutôt que de simplement migrer nos Styles existants vers une nouvelle fonctionnalité.
J’ai commencé par auditer la structure existante, puis organisé les tokens selon trois niveaux :
primitive → semantic → component
Les valeurs brutes étaient ainsi séparées de leur intention d’usage, puis des décisions propres à chaque composant. Nous avons progressivement remappé les composants sur cette architecture, ce qui nous permettait de centraliser davantage de règles et de les propager plus systématiquement dans le système.
L’objectif n’était pas d’automatiser le responsive, mais de rendre le système plus simple à faire évoluer de manière cohérente et moins dépendant de corrections manuelles locales.
Architecture des tokens
Semantic
Signification / intention d’usage
La fonction d’une valeur dans le produit, afin que son intention soit définie une fois puis réutilisée.
Component
Décisions propres au composant
Les choix spécifiques à un composant, conservés en dehors des couches partagées.
Une règle modifiée, plusieurs contextes mis à jour
J’ai standardisé les valeurs d’espacement et de radius afin d’améliorer la cohérence visuelle entre les composants.
J’ai ensuite utilisé les Variables pour simplifier les déclinaisons d’écrans sur nos trois tailles, Lg, Md et Sm, en centralisant les valeurs qui variaient entre elles. Cela réduisait les ajustements manuels répétitifs et le risque d’incohérences sur de grands ensembles d’écrans.
J’ai également structuré un mode de thème Light/Dark afin d’anticiper un éventuel dark mode sans dupliquer le système.
Démonstration en conditions réelles
Faire du Design System une référence réellement utilisable
Mettre à jour la bibliothèque Figma ne suffisait pas si les règles qui la structuraient restaient implicites.
J’étais responsable de la documentation du Design System dans ZeroHeight, qui servait de référence aux développeurs et aux autres équipes travaillant sur L’Identité Numérique La Poste.
Après la V2, j’ai repris cette documentation dans son ensemble. J’ai benchmarké plusieurs Design Systems matures, réorganisé certaines parties de la structure et documenté les comportements des composants, leurs usages attendus, les guidelines ainsi que les principaux Do / Don’t.
J’ai ensuite maintenu cette documentation au fil des évolutions du système, en travaillant avec l’autre UI Designer chaque fois qu’une règle nécessitait une décision commune.
La couche derrière la qualité
Chaque couche ne tient que si celle qui la sous-tend est explicite
- Interfaces produitCe que les utilisateurs expérimentent réellement
- Composants réutilisablesDes réponses communes à des problèmes récurrents
- Architecture des tokensPrimitive · Semantic · Component
- DocumentationQuand, pourquoi et comment utiliser une règle
- ImplémentationLà où les décisions sont éprouvées
04Implémentation
Maintenir la qualité UI jusqu’à l’implémentation
Notre responsabilité ne s’arrêtait pas une fois les maquettes validées.
Avant chaque handoff, nous préparions des fichiers de delivery dédiés et repassions sur les écrans pour vérifier l’utilisation des composants, la cohérence, les différents états et les détails nécessaires à l’implémentation.
Les maquettes étaient ensuite publiées dans Zeplin, avec une organisation distincte pour iOS, Android et Web. Pendant le développement, un canal UI/Dev dédié permettait aux développeurs de revenir directement vers nous lorsqu’une spécification ou un comportement nécessitait d’être clarifié.
Une fois une fonctionnalité développée, je participais à la QA design et fonctionnelle dans un environnement de test. Lorsqu’un écart apparaissait entre l’implémentation et l’expérience prévue, nous le documentions, créions des tickets et travaillions avec les développeurs sur les corrections nécessaires avant la mise en production.
Les mêmes règles définies dans le Design System se prolongeaient ainsi à travers le design, le handoff, l’implémentation et la QA. La qualité UI ne s’arrêtait pas à Figma.
- Design
- Fichiers de delivery
- Zeplin
- Développement
- QA
- Correction
- Mise en production
05Réflexion
Avec le recul
Ce projet a fait évoluer ma manière de considérer le craft UI. Sur un produit qui évolue au sein de plusieurs squads, la qualité ne dépend pas uniquement de la précision d’une interface prise isolément. Elle dépend aussi des règles, composants, conventions et processus qui permettent à cette précision de rester cohérente dans le temps.
Lorsqu’un même problème apparaît de manière répétée, la réponse la plus pertinente n’est souvent pas une nouvelle correction locale, mais une solution commune qui améliore le système derrière l’expérience.
C’est cette manière de penser à l’échelle du système que j’ai ensuite continué à appliquer dans mes projets de Product Design.
