A look back at the first AI Design Sprint at BNP Paribas

Today, we are taking you behind the scenes of the first AI Design Sprint organized at BNP Paribas BCEF, with Cédric Marteau (Design Director at Source.paris and Design Strategist at BNP Paribas BCEF), who structured a day dedicated to AI-assisted prototyping for 70 designers.

A huge thank you to the BNP Paribas BCEF Design team for allowing us to talk about it today.

The BNP Paribas BCEF Design team

“It is no longer the designers who push the methodology, it is the business lines that are demanding it.”

This is the most unexpected result of the AI-assisted Design Sprint we conducted with the BNP Paribas BCEF Design team (70 people).
The request to continue and industrialize the practice came from the business teams (PMs, developers, top management). A look back at what made this result possible, and what we should not make it say.

Four days to test delight

Last month, the BNP Paribas BCEF Design team organized a four-day AI-assisted Design Sprint, with the objective of generating and testing differentiating ideas for the “Mes Comptes” application, particularly those capable of bringing delight, in the sense defined by Nesrine Changuel in her book.

The sprint follows a classic Discovery structure compressed to fit into four days and relies on Personas established beforehand by the UX Research team.

• Empathy: presentation of research findings and Personas

• Problem space: what are the problems encountered by our targets?

• Solution space: “How might we…?” then prototyping

• Prioritization “Impact Effort” by PMs and developers

And the bet paid off: several concepts from the sprint were selected for the “Mes Comptes” application, some deemed to bring delight during the prioritization phase.

It remains to understand how such a result was made possible in such a short time.

Documenting expertise to manage 18 simultaneous teams

My role was to build a scoping methodology and a technical environment that would allow each team to prototype their concept with ambition and efficiency within the allotted time.

Scoping an exercise on this scale required transforming individual expertise into actionable instructions for the AI:

• A PRD (Product Requirements Document) builder structured the product approach step-by-step.

• An Expert file injected business knowledge and the benchmark. Concretely, this file contained instructions such as: “BNP Paribas has a network called Global Alliance that allows free withdrawals in many countries.”

• A Persona file allowed each team to talk directly to their target audience.

• Guidelines framed compliance with the visual and editorial guidelines.

The entire set-up was built on markdown files.

The first observation relates to the impact of this documentation. The markdown files multiplied my usual role as a Design Strategist across the eighteen simultaneous teams, without requiring physical presence to guide or influence design choices. But this delegation has a cost: a written instruction does not replace a live discussion. Some teams had to decide on their own in situations that the files had not anticipated (a Persona contradicting the benchmark, a user journey case missing from the PRD). In person, a quick question would have settled this in thirty seconds.

Excerpts from the .md files provided to participants

The critical eye of the Designer remains decisive, starting right from the writing of the documentation

This impact raises a legitimate question: what role is left for the designer if expertise is documented in files? Two answers:

The first relates to the nature of these .md files themselves. Writing them is already an act of Design, and this is where my role as Lead Strategist shifted: choosing what the Expert file retains of the business knowledge, what the Persona says about the target, what the guidelines impose on the design system—all of which are decisions that direct each product screen subsequently created. And this work does not stop at their first version. They are neither final nor perfect. For the next AI Design Sprint, I will dedicate more time to them. They must be considered living documentation, continuously fueled by the evolution of usages, technologies, and the market.

The second touches on the role of the designer themselves. The most successful works of the sprint owe their success to what AI alone could not bring: features accurately grounded in the existing application, consistent with the products in place, adjusted to their target. This detailed knowledge of the existing system went beyond what the files documented.
Conversely, the least successful results came from teams that let the AI decide for them without challenging its proposals. Some lacked time, familiarity with the tool, and were sometimes slowed down by bugs.

Producing a screen now takes a few seconds. Knowing where it should live, what it must remain consistent with, and for whom, remains the designer's job. This is indeed the conviction we hold at Source.paris: the designer's role increases in value as AI tools become widespread.

A dedicated mini-site hosts the 18 prototypes of the session containing for each: description, code, and pitch (video + slides)

An assumed limit: the sprint accelerates Discovery, the finished product still needs to be designed

AI-assisted prototyping is a powerful vehicle for Discovery. The interactive medium allows testing in conditions close to reality, in a few days rather than weeks. This speed has a clear limit. It validates directions, but not technical architectures, nor user journeys that comply with the Design, technical, or legal requirements of BNP Paribas.

A second limit relates to the nature of the screens produced during the sprint, which were partly generated by AI. The copy often remains verbose and unpolished, and some conceptual models are still questionable with regard to the ambition of a best in class experience. These imperfections are the normal consequence of a conception time compressed into four days. In Design, simplicity is acquired through an iterative process of refinement: removing one layer after another until the most obvious solution is reached. This is precisely what the speed of the sprint does not allow, even when assisted by AI.

Designing for production remains a complete job in its own right, outside the scope of this sprint.

A signal of Design maturity

This first edition has a direct consequence on the place of Design in the organization. The PMs, developers, and top management who participated in the sprint are now encouraging us to deploy the approach at the squad level, to dig into a specific problem around a product whereas the sprint addressed the application as a whole.

This shift in scale is being driven by voices outside of Design, making it the most concrete signal of the sprint's impact. This shift marks a notable rise in Design maturity within the organization, more than the sprint itself.

It also determines what comes next. Scaling to the squads presents a known challenge: getting more people on board without losing what made the quality of the exercise in the first place.

The quality of the sprint lies in the scoping rather than the AI itself.

This scoping is therefore the first thing that will need to be industrialized: the files, the methodology, the pilot role of the designer. The next edition, at a squad level, will serve to verify this.