NéMO

Quand j’ai rejoint le projet, une partie des fondations visuelles étaient déjà en place, notamment une palette de couleurs sur laquelle j’ai identifié des marges de progression en termes de contraste : un point particulièrement sensible pour une appli pensée pour être utilisée en mobilité, souvent en extérieur avec des reflets sur l’écran. J’ai fait évoluer le contraste chaque fois que le cadre existant le permettait.

Plus largement, l’enjeu était de rendre l’ensemble du parcours plus clair et plus rapide : une inscription simple, une activation des services sans friction inutile, et une lecture immédiate de l’information même dans un contexte d’usage pressé : en attendant un bus ou en marchant

J’ai commencé par un audit de l’existant pour identifier précisément où se situaient les points de friction : contraste, hiérarchie visuelle, longueur du parcours.

Cet audit m’a servi de base pour prioriser mes efforts plutôt que de tout refondre sans distinction.

J’ai ensuite cartographié les parcours utilisateurs pour visualiser l’ensemble du chemin, de la découverte de l’appli jusqu’à l’usage régulier des services de mobilité, en repérant les étapes où l’expérience se complexifiait inutilement. Ce travail a nourri des user flows plus précis pour chaque scénario clé (inscription, activation d’un service, consultation hors ligne).

Le prototypage m’a permis de tester rapidement plusieurs pistes avant de m’engager dans le détail visuel et le projet a évolué par itérations successives : chaque version affinant la lisibilité, la hiérarchie de l’information ainsi que la fluidité du parcours.

Sur la partie itinéraires, j’avais exploré une refonte visant à éviter les nœuds et les culs-de-sac visuels dans l’affichage des trajets, et à mieux distinguer les différents moyens de transport combinés sur un même trajet, au-delà de l’aspect esthétique, l’objectif était avant tout de rendre le trajet plus facile à suivre d’un coup d’œil.

Sur le ticket dématérialisé, la contrainte principale était différente : l’espace disponible ne permettait pas d’ajouter de nouvelles fonctionnalités sans surcharger l’écran, pour un document consulté aussi bien par l’utilisateur que par les contrôleurs. J’ai fait le choix de hiérarchiser strictement l’information, en rendant immédiatement visibles les données et les actions les plus importantes pour les deux usages, plutôt que d’ajouter du contenu au détriment de la lisibilité.

Ce projet s’est beaucoup joué dans les marges de manœuvre disponibles, plutôt que dans une liberté totale.

Sur MyBus, une partie de la palette de couleurs n’était pas modifiable, j’ai dû composer avec, en poussant le contraste aussi loin que le cadre le permettait, pour que l’appli reste lisible même en plein soleil, dans les transports. Sur les déclinaisons en marque blanche en revanche, j’avais davantage de latitude pour ajuster ce contraste selon chaque client.

Autre réalité du terrain : les API de billettique existantes avaient leurs propres règles, pas toujours alignées avec ce qu’on aurait voulu proposer dans l’idéal. Plutôt que de les subir, j’ai cherché à concevoir des composants suffisamment modulaires pour s’y adapter sans perdre en cohérence.

Avec le recul, je pense qu’investir plus tôt dans de meilleurs outils de collaboration, notamment sur la gestion des variables Figma (mais qui n’existait pas au début), aurait encore fluidifié certains échanges et fait gagner du temps sur les déclinaisons.

C’est aussi le projet où j’ai le plus poussé l’automatisation dans ma pratique : la logique de SVG paramétrables et recolorisables m’a fait monter significativement en niveau sur Figma, une compétence que je réutilise depuis sur tous mes projets impliquant de la déclinaison ou de la personnalisation à grande échelle.