Problématiques et solutions
Design System sous contraintes
Problématique 1: Reconstruire entièrement le Design System en parallèle de
la refonte en prenant en compte les nouvelles fonctionnalités encore en cours de conception
fonctionnelle. Chaque composant devait anticiper de multiples cas d'usage dès sa création.
L'ajout d'une ou deux informations supplémentaires pouvait remettre en cause un composant
entier et toutes ses déclinaisons. Sans vue d'ensemble complète, il était difficile
d'établir des
guidelines précises et de prendre en compte tous les cas d'usage.
Solution : Construction itérative du Design System en avançant par parcours
prioritaires: achat, validation, gestion de compte, abonnements, pour permettre aux
équipes dev de démarrer sur une base stable. Chaque composant a été conçu pour absorber les
évolutions fonctionnelles sans tout recasser, avec des guidelines documentées au fur et à
mesure pour maintenir la cohérence malgré les allers-retours entre conception et
développement.
Couleurs et accessibilité
Problématique 2: En marque blanche, la tint color est choisie par chaque
réseau client. Certaines teintes comme le rose flashy, le jaune vif, ou les tons pastels
rendaient
illisibles les boutons secondary, liens et pictogrammes conçus pour afficher la couleur
réseau. Impossible de garantir la conformité WCAG sur des éléments dont la couleur échappe
à mon contrôle de Designer.
Solution : Définir une règle d'usage claire dès la conception du Design
System. La tint color est réservée aux éléments non porteurs de sens critique : boutons
primary, background header, pictogrammes décoratifs, fond de ticket en opacité réduite. Les
éléments importants pour la compréhension comme les liens ou les pictogrammes fonctionnels,
reçoivent une
couleur neutre (noir, blanc, gris) indépendante de la tint color. Cette approche a permis
d'atteindre entre autres critères, 93% de conformité WCAG, validée par audit sur Android et
iOS avec tests de
lecteurs d'écran.
Tests utilisateurs et itérations
Problématique 3: Les parcours principaux avaient été conçus sur la base de
l'existant et des retours internes, avec peu de données utilisateurs réelles. Avant le
déploiement auprès des réseaux clients, il fallait valider les choix de conception et
identifier les frictions restantes.
Solution : Mise en place de tests utilisateurs formels: 3 parcours
prototypés sur Figma, grilles d'évaluation, panel de 10 testeurs en présentiel et à
distance. Le parcours le moins bien noté (3,5/5) était la gestion de
compte : les utilisateurs ne trouvaient pas les factures et étaient frustrés par le contenu
masqué derrière des sections pliables. Corrections apportées : renommage de "mes commandes"
en "mes achats et factures", et suppression du système masquage/affichage au profit d'une
liste complète scrollable par catégorie.
Internationalisation
Problématique 4: m-Ticket est déployé en France mais aussi en Italie,
Espagne, Royaume-Uni et au-delà. L'application est traduite en huit langues. Or les
composants et écrans étaient conçus en français mais certaines langues génèrent des textes
significativement plus longs, mettant en péril la tenue des composants, le wording des
boutons et l'espacement des éléments.
Solution : Intégrer la contrainte de traduction dès la phase de conception.
Anticiper les variations de longueur de texte dans la définition des tailles de texte, des
marges et des emplacements. Chaque composant a été pensé pour absorber les débordements les
plus fréquents sans casser la mise en page, quelle que soit la langue affichée.