Bpifrance est la banque publique d'investissement française, ayant pour mission le financement et le développement des entreprises. L’écosystème de Bpifrance étant très grand, cela induit un fort besoin en design pour leurs divers produits digitaux. La solution pour répondre à ce besoin ? La régie ! Elle m’a permis en tant que designer Wolfox de travailler en étroite collaboration avec une équipe spécifique dédiée au projet suivant : BOost.
L’équipe s’organise sous forme de sprint en méthode agile. De nombreux outils et méthodologies sont mis en place afin de garantir une organisation sans faille. En tant que designer, je suis encadrée par un Product Owner qui détient déjà toute la vision produit du projet. C’est pour moi ma première expérience en équipe produit et je suis très rapidement mise en confiance grâce à l’étroite collaboration et communication qui est imposée.
Dans ce sens, côté design, il faut que les maquettes produites soient faisables techniquement afin de garantir une implémentation rapide de nouvelles fonctionnalités qui donnent de l’impact aux utilisateurs.
Le produit a une particularité : il y a deux design system existants, un premier implémenté en interne et un second tiré d’une libraire externe pour des besoins spécifiques. Malheureusement, les rituels sprint existants étaient insuffisants pour traiter les questions d’intégration de notre librairie de composants externe. Pourquoi ? Tout simplement parce qu’il fallait les créer de 0 et qu’il faut “du temps” pour identifier toutes les contraintes techniques qui s’y prêtent pour pouvoir y procéder.
Nous avons donc mis en place un nouveau rituel de “challenge maquettes”. Ce point consiste à présenter aux devs plusieurs propositions de maquettes et nous tranchions ensemble sur celle qui était à la fois la plus adaptée en fonction de l’usage utilisateur et la plus facile à implémenter techniquement. Rituel essentiel que je retiens pour nourrir mon expertise en tant que Lead product designer !
Au démarrage de ma première mission chez Bpifrance, il y a eu énormément d’informations à digérer liées au domaine d’expertise du produit. Ça a été difficile pour moi de comprendre tous les enjeux actuels pour pouvoir aider l’équipe à renforcer sa stratégie produit. Pour me faciliter la tâche, je me rendais chaque jour en présentiel chez le client : le partage de connaissances avec l’équipe concernant le produit a été très efficace et donc mon onboarding aussi !
Qui dit échanges et communication, dit interviews et tests utilisateurs réguliers. Cet exercice est essentiel pour tester les maquettes et identifier les “edges cases” que seuls les utilisateurs peuvent rencontrer.
Les edges cases c’est quoi ? Ce sont des scénarios particuliers où un utilisateur utilise un produit selon son prisme et ses besoins. Ces situations, souvent négligées, peuvent avoir un impact significatif sur l'expérience utilisateur. Grâce aux tests, nous pouvons identifier ces cas et adapter le produit en conséquence, assurant ainsi sa flexibilité et sa pertinence pour un large éventail de besoins utilisateur.
De ce fait, en amont d’un test utilisateur, il est essentiel de préparer un protocole avec une liste d’hypothèses (idées reçues de l’utilisation du produit) que nous allons faire tester. Cela devient alors essentiel pour créer un produit basé sur des besoins réels et non des perceptions d’utilisation biaisées.
Pour rappel, le projet BOost est un outil Bpifrance qui permet la vérification documentaire de pièces justificatives constituant un dossier pour une demande de prêt.
Afin d’aider les agents qui réalisent ces tâches à être plus efficaces, nous avons mis en place une technologie d’identification automatique des erreurs. L’objectif est de prioriser l’affichage des erreurs en fonction de leur “gravité”. Cette solution réduit la charge mentale des agents en leur “pré-machant” leur travail et en ayant une analyse très visuelle avec un code couleur intuitif. Bien évidemment que les règles d’accessibilité ont été respectées et mises en place, notamment sur les niveaux de contrastes des couleurs.
Exemple : un de nos utilisateurs est daltonien, c’est à dire que cela affecte principalement sa perception des couleurs primaires comme le rouge, le vert et le bleu et donc il les confond. C’est pour cela que la couleur ne suffit pas : le texte est essentiel pour donner du sens au message “3 erreurs détectées”, “1 cas de vigilance”, “21 contrôles validés”. Plus il y a de codes graphiques de nature différente pour renforcer le sens d’une information, plus on donne de chance à l’utilisateur de le comprendre. Par exemple ici il aurait été super intéressant d’ajouter en plus une icône “croix” pour le cas d’erreur, de ce fait notre ami daltonien comprend le texte mais également l’icône lorsqu’il y a une erreur.