Retour sur le premier Design sprint IA chez BNP Paribas

Aujourd'hui nous vous ouvrons les coulisses du premier Design Sprint IA organisé chez BNP Paribas BCEF, avec Cédric Marteau (Design Director chez Source.paris et Design Strategist chez BNP Paribas BCEF) qui a architecturé une journée dédiée au prototypage assisté par IA pour 70 designers.

Un grand merci à l’équipe Design de BNP Paribas BCEF de nous permettre d’en parler aujourd’hui.

L’équipe Design de BNP Paribas BCEF

“Ce ne sont plus les designers qui poussent la méthode, ce sont les métiers qui la réclament.”

Voilà le résultat le plus inattendu du Design sprint assisté par IA que nous avons mené avec l’équipe Design de BNP Paribas BCEF (70 personnes).
La demande de continuer et industrialiser la pratique est venue des équipes métiers (PMs, développeurs, top management). Retour sur ce qui a rendu ce résultat possible, et sur ce qu'il ne faut pas lui faire dire.

Quatre jours pour tester le delight

L’équipe Design de BNP Paribas BCEF a organisé le mois dernier un Design sprint assisté par IA sur quatre jours, avec comme objectif de générer et tester des idées différenciantes pour l’application “Mes Comptes”, en particulier celles capables d’apporter du delight, au sens défini par Nesrine Changuel dans son ouvrage.

Le sprint reprend une structure de Discovery classique compressée pour tenir en quatre jours et s’appuie sur des Personas établis au préalable par l’équipe UX Research.

• Empathy : présentation des résultats de recherche et Personas

• Problem space : quels sont les problèmes rencontrés par nos cibles ?

• Solution space : “How might we…?” puis prototypage

• Priorisation “Impact Effort” par les PMs et les développeurs

Et le pari est tenu : plusieurs concepts issus du sprint sont retenus pour l’application “Mes Comptes”, certains jugés porteurs de delight lors de la priorisation.

Reste à comprendre comment un tel résultat avait été rendu possible en un temps aussi court.

Documenter l’expertise pour piloter 18 équipes en simultané

Mon rôle a été de construire une méthodologie de cadrage et un environnement technique permettant à chaque équipe de prototyper son concept avec ambition et efficacité dans le temps imparti.

Cadrer un exercice à cette échelle imposait de transformer une expertise individuelle en instructions exploitables par l’IA :

• Un constructeur de PRD (Product Requirements Document) a structuré la démarche produit étape par étape.

• Un fichier Expert a injecté la connaissance métier et le benchmark. Concrètement, ce fichier contenait des instructions du type : “BNP Paribas dispose d’un réseau nommé Global Alliance qui permet de retirer gratuitement dans de nombreux pays”.

• Un fichier Persona a permis à chaque équipe de dialoguer directement avec sa cible.

• Des consignes ont cadré le respect de la charte visuelle et éditoriale.

L’ensemble reposait sur des fichiers markdown.

Le premier constat tient à l’impact de cette documentation. Les fichiers markdown ont démultiplié mon rôle habituel de Design Strategist auprès des dix-huit équipes en simultané, sans présence physique nécessaire pour guider ou influencer les choix de design. Mais cette délégation a un coût : une consigne écrite ne remplace pas un échange en direct. Certaines équipes ont dû trancher seules des situations que les fichiers n’avaient pas anticipées (un Persona qui entrait en contradiction avec le benchmark, un cas de parcours absent du PRD). En présentiel, une question réglait cela en trente secondes.

Extraits des fichiers .md fournis aux participants

Le regard critique du Designer reste décisif, dès l’écriture de la documentation

Cet impact soulève une question légitime : quel rôle reste au designer si l’expertise est documentée dans des fichiers ? Deux réponses :

La première tient à la nature de ces fichiers .md eux-mêmes. Les écrire est déjà un acte de Design, et c’est là que mon rôle de Lead Strategist s’est déplacé : choisir ce que le fichier Expert retient de la connaissance métier, ce que le Persona dit de la cible, ce que les consignes imposent de la charte, autant d’arbitrages qui orientent chaque écran produit ensuite. Et ce travail ne s’arrête pas à leur première version. Ils ne sont ni définitifs ni parfaits. Pour le prochain Design sprint IA, j’y consacrerai davantage de temps. Ils doivent être considérés comme une documentation vivante, nourrie en continu par l’évolution des usages, des technologies et du marché.

La seconde touche au rôle du designer lui-même. Les travaux les plus aboutis du sprint doivent leur réussite à ce que l’IA seule ne pouvait pas apporter : des fonctionnalités ancrées avec justesse dans l’application existante, cohérentes avec les produits en place, ajustées à leur cible. Cette connaissance fine de l’existant dépassait ce que les fichiers documentaient.
À l'inverse, les résultats les moins aboutis viennent des équipes qui ont laissé l'IA décider à leur place sans challenger ses propositions. Certaines ont manqué de temps, d'aisance avec l'outil, et se sont parfois retrouvées freinées par des bugs.

Produire un écran prend désormais quelques secondes. Savoir où il doit vivre, avec quoi il doit rester cohérent et pour qui, reste le travail du designer. C’est d’ailleurs la conviction que nous portons chez Source.paris : le rôle du designer gagne en valeur à mesure que les outils IA se généralisent.

Un mini-site dédié héberge les 18 prototypes de la session avec pour chacun : description, code et pitch (vidéo + slides)

Une limite assumée : le sprint accélère la Discovery, le produit fini reste à concevoir

Le prototypage assisté par IA constitue un vecteur de Discovery puissant. Le support interactif permet de tester en conditions proches du réel, en quelques jours plutôt qu’en semaines. Cette rapidité a une limite claire. Elle valide des directions, mais pas des architectures techniques, ni des parcours conformes aux exigences Design, techniques ou encore légales de BNP Paribas.

Une seconde limite tient à la nature des écrans produits pendant le sprint, en partie générés par l’IA. Les wordings restent souvent verbeux et peu fluides, et certains modèles conceptuels demeurent encore discutables au regard de l’ambition d’une expérience best in class. Ces imperfections sont la conséquence normale d’un temps de conception compressé sur quatre jours. En Design, la simplicité s’acquiert par un travail itératif d’épuration : retirer une couche après l’autre jusqu’à la solution la plus évidente. C’est précisément ce que la vitesse du sprint ne permet pas, même assisté par l’IA.

La conception pour une mise en production reste un travail à part entière, hors du périmètre de ce sprint.

Un signal de maturité de Design

Cette première édition a une conséquence directe sur la place du Design dans l’organisation. Les PMs, les développeurs et le top management qui ont participé au sprint nous encouragent désormais à déployer la démarche à l’échelle des squads, pour creuser une problématique précise autour d’un produit là où le sprint traitait l’application dans son ensemble.

Ce déplacement d’échelle est porté par des voix extérieures au Design, ce qui en fait le signal le plus concret de l’impact du sprint. C’est ce déplacement qui marque une montée en maturité Design notable de l’organisation, plus que le sprint lui-même.

Il conditionne aussi la suite. Passer à l’échelle des squads pose une difficulté connue : embarquer davantage de monde sans perdre ce qui a fait la qualité de l’exercice.

La qualité du sprint tient au cadrage davantage qu’à l’IA elle-même.

C’est donc ce cadrage qu’il faudra industrialiser en premier : les fichiers, la méthodologie, le rôle de pilotage du designer. La prochaine édition, à l’échelle d’une squad, servira à le vérifier.