Sept personnes, 21 conversations : ce qu'une équipe m'a appris sur la façon de construire un produit

Comment une équipe pluridisciplinaire (devs, DA, marketing, UX) a façonné un produit : d'où viennent les idées, pourquoi se coordonner est dur, ce qui aide.

Mettez sept personnes sur un projet et vous n'obtenez pas sept lignes de communication. Vous en obtenez 21.

Le calcul est simple : chaque personne peut parler à chacune des autres, donc une équipe de n personnes a n × (n − 1) / 2 conversations possibles. Fred Brooks l'a écrit en 1975, dans The Mythical Man-Month, pour expliquer pourquoi ajouter des gens à un projet logiciel en retard tend à le retarder encore plus (la loi de Brooks). Trois personnes partagent 3 conversations. Sept en partagent 21. Chacune peut porter une idée, et chacune peut en perdre une.

Pendant les deux années de mon master, j'ai vécu dans ces 21 conversations. Le projet s'appelait Pawka, une application mobile qui scanne les aliments pour animaux et transforme une liste d'ingrédients illisible en un score sur 100. L'équipe : trois développeurs, deux directeurs artistiques, une personne en marketing, et moi sur la recherche UX et le design d'interface.

Voici la partie à laquelle je ne m'attendais pas. La décision qui a fait fonctionner Pawka ne venait pas de moi.

La meilleure idée n'était pas la mienne

Ma partie du projet, c'étaient les utilisateurs. La recherche derrière Pawka comptait 12 entretiens semi‑directifs, trois sessions d'observation en magasin et un benchmark concurrentiel. On savait que nos utilisateurs passaient en moyenne 4 minutes 20 au rayon animalerie, et que 92 % d'entre eux avaient du mal à lire une étiquette standard.

Ce que je n'avais pas, c'était le modèle économique. Puis le mode invité est venu de l'extérieur de la partie UX : laisser les gens scanner cinq produits par jour sans aucun compte, et ne leur demander de s'inscrire qu'au moment où ils veulent enregistrer un favori ou consulter leur historique. Une offre gratuite d'abord, le Premium ensuite.

Sur le papier, ça ressemblait à une décision marketing. En pratique, c'était la meilleure décision UX de l'application.

Dans la cartographie des frictions du parcours utilisateur, « inscription obligatoire avant le premier scan » était le seul problème noté 5 sur 5 : demander un engagement avant de montrer la moindre valeur détruit la conversion. En test, un participant l'a dit mieux que n'importe quel graphique : « Je pouvais explorer sans rien donner. C'est rassurant pour quelqu'un comme moi qui se méfie des applis. »

La recherche et le modèle économique pointaient donc vers la même porte. J'avais la preuve de l'endroit où ça faisait mal. Un coéquipier avait la solution. Aucun de nous ne l'aurait livrée seul.

Pourquoi les équipes pluridisciplinaires ont de meilleures idées (quand elles fonctionnent)

C'est la promesse d'une équipe pluridisciplinaire, et la recherche la confirme.

En 2010, Anita Woolley et ses collègues ont confié à des groupes de deux à cinq personnes une grande variété de tâches, et ont trouvé quelque chose comme un facteur d'intelligence collective : certains groupes réussissaient bien partout. Ça ne s'expliquait pas par l'intelligence du membre le plus brillant. C'était lié à la sensibilité sociale des membres, et au fait que tout le monde prenait la parole, au lieu d'une ou deux voix qui monopolisent la salle.

Google a trouvé un schéma proche en étudiant ses propres équipes dans le Projet Aristote. Parmi les cinq dynamiques qui distinguent les équipes efficaces, la sécurité psychologique arrivait en tête : la conviction partagée qu'on peut prendre un risque devant ses coéquipiers sans être puni. L'idée remonte à l'étude d'Amy Edmondson sur les équipes de travail, en 1999, qui reliait la sécurité psychologique à ce que les équipes apprennent réellement.

Traduit en projet étudiant : l'idée du mode invité n'arrive sur la table que si la personne qui l'a se sent autorisée à apporter une idée business dans une discussion UX. Et elle ne survit que si la personne UX ne traite pas sa recherche comme un territoire.

Collaboration à distance : le vrai ennemi, c'était le calendrier

Mais je mentirais en disant que la difficulté, c'étaient les idées. La difficulté, c'était le temps.

Sept étudiants, c'est sept emplois du temps : des cours différents, des échéances différentes, sur deux ans. Réussir à avoir tout le monde disponible au même moment a été la partie la plus dure de tout le projet, et une bonne partie de la coordination s'est faite à distance.

La recherche sur le travail à distance décrit exactement ce que ça fait à une équipe. Quand Microsoft a renvoyé tous ses salariés chez eux en 2020, une étude portant sur plus de 61 000 employés a montré que la collaboration devenait plus cloisonnée et plus asynchrone : moins de liens entre les groupes, moins d'appels en direct, plus d'e‑mails et de messages. L'information circulait toujours, mais plus lentement, et moins souvent d'une discipline à l'autre.

C'est le danger pour une équipe mixte. Les développeurs finissent par parler aux développeurs, les directeurs artistiques aux directeurs artistiques, et les 21 conversations se réduisent sans bruit à trois.

Ce qui a tenu Pawka ensemble, ce sont donc les choses qu'on pouvait lire sans que personne soit dans la pièce.

Un design system comme contrat

On a traité le design system comme un contrat entre le design et le développement. Il suivait l'Atomic Design : les fondations, puis les atomes comme les boutons, badges et champs avec tous leurs états documentés, puis les molécules comme la carte de critère, puis les organismes comme la fiche produit complète. Un développeur qui travaillait à une autre heure que moi n'avait pas besoin de m'écrire pour savoir à quoi ressemblait un bouton désactivé. La réponse était déjà écrite.

Il y a une vieille règle cachée là‑dessous. En 1968, Melvin Conway observait que les organisations conçoivent des systèmes qui reproduisent leur propre structure de communication. Si votre équipe ne peut se parler qu'en asynchrone, votre produit prendra la forme de ce que vous avez réussi à écrire. Alors écrivez les bonnes choses.

Des retours avant les pixels

Chaque wireframe passait par deux ou trois tours de retours internes avant de passer en haute fidélité. À ce stade, les écrans étaient volontairement moches, juste de la structure. Ça les rendait faciles à critiquer. Personne n'hésite à dire « ce parcours est confus » devant des boîtes grises, et une remarque de directeur artistique sur la hiérarchie ne coûte rien à appliquer tant qu'aucune couleur n'existe.

Les personas comme arbitres

On a fini avec sept profils, dont deux anti‑personas, et chaque décision de design devait dire lequel elle servait. Ça ressemble à du processus pour le plaisir du processus. Dans une équipe où trois disciplines ne sont pas d'accord, c'est l'inverse : la discussion passe de « je pense que » à « Claire, au milieu du rayon avec deux minutes pour choisir, a besoin de ça ».

Le résultat : ce qu'ont montré les tests utilisateurs

La preuve que l'équipe a fonctionné se trouve dans les tests. 100 % des participants se souvenaient encore du score et de sa couleur après avoir regardé une fiche produit cinq secondes. L'application a obtenu 80 au System Usability Scale, soit un niveau « bon ». Et la seule tâche qui a peiné, trouver comment le score est calculé, n'a atteint que 50 % de réussite directe. La correction est partie directement en tête de la feuille de route : un bouton « Comment est calculé ce score ? » sur chaque fiche produit.

Conseils de travail d'équipe pour une équipe produit qui démarre

• Comptez vos conversations. À sept, décidez lesquelles des 21 doivent vraiment se faire en direct, et donnez à tous les autres échanges un endroit écrit.
• Laissez la recherche arbitrer, pas l'ancienneté. Un persona ou un score de sévérité clôt un débat plus vite qu'un intitulé de poste.
• Écrivez chaque décision là où la personne suivante regardera. Si elle n'existe que dans un fil de discussion ou dans la mémoire de quelqu'un, pour la personne qui arrive lundi, elle n'a pas eu lieu.
• Rendez sûr le fait d'apporter des idées hors de son rôle. Notre meilleure décision UX est venue de l'extérieur de l'UX.
• Protégez un créneau en direct par semaine. Faites tout le reste en asynchrone, mais gardez un moment où toutes les disciplines sont dans le même appel au même moment, pour que les silos ne se referment pas.
• Créditez les idées par leur nom. Les gens continuent d'apporter des idées aux équipes où l'on se souvient d'où elles viennent.

Cinq scans gratuits

Vous pouvez lire l'étude de cas Pawka en entier, des 12 entretiens aux résultats des tests en passant par le design system.

Mais si on me demande ce que le travail en équipe m'a appris, je montrerai l'écran le plus banal de l'application : cinq scans gratuits, sans compte. Ça ressemble à un petit détail d'UX. C'est le seul endroit où une idée business, un résultat de recherche et la phrase d'un utilisateur méfiant sont tombés exactement au même endroit.

Ce n'est pas moi qui l'ai trouvée. J'ai aidé à prouver qu'elle était juste. C'est à ça que sert une équipe.