Le Double Diamond applique a la conception de plugins
Comment PluginFactory utilise le framework Double Diamond pour concevoir des plugins Claude Code qui resolvent le bon probleme.
La plupart des projets de plugins echouent parce qu'on a resolu le mauvais problème. Un CTO demande un plugin de review de code. On le construit. Trois semaines plus tard, personne ne l'utilise. Le vrai problème n'était pas la review. C'était le manque de contexte partage entre les devs au moment de pousser du code.
MIT Sloan estime que le taux d'échec des nouveaux produits se situe entre 30 et 80% selon la maturité de l'entreprise. La cause principale ? L'absence de validation du problème avant la construction. Chez PluginFactory, on utilise le Double Diamond pour éviter ce piège. Et le framework se mappe parfaitement sur notre workflow de conception de plugins.
Deux diamants, un service
Le Design Council UK a formalise le Double Diamond en 2005. Le principe : deux phases de divergence (explorer large) suivies de deux phases de convergence (focaliser). Le premier diamant trouve le bon problème. Le second trouve la bonne solution.
Chez PluginFactory, le premier diamant correspond a notre phase d'audit et de discovery call. Le second correspond a la conception et au déploiement. On ne code pas un plugin avant d'avoir traverse les deux diamants. C'est plus lent au départ. Mais ça evite de jeter trois semaines de travail parce qu'on a mal compris le besoin.
Mais attention
Le Double Diamond ne veut pas dire livraison lente. Ça veut dire moins de retravail. Un plugin bien cadre au premier diamant se construit en une fraction du temps qu'un plugin mal cadre qui subit trois iterations de correction. Le temps investi en discovery est recupere en conception.
L'erreur serait de transformer le Double Diamond en processus bureaucratique. Chez PluginFactory, le premier diamant prend une a deux semaines. Pas deux mois. L'objectif est la clarté, pas l'exhaustivité.
En resume
- Le Double Diamond mappe directement sur le workflow PluginFactory : audit, définition, conception, déploiement.
- Le premier diamant evite le piège classique : construire un plugin que personne n'utilise parce que le problème était mal identifie.
- Explorer plusieurs architectures avant d'en choisir une réduit le retravail et augmente l'adoption.
- Valider avec les devs, pas le management : les utilisateurs finaux sont les seuls juges de la désirabilité.
- Discovery ne veut pas dire lenteur : une a deux semaines de cadrage economisent des semaines de correction.
Le meilleur plugin est celui qu'on ne recode pas parce qu'on a pris le temps de comprendre le vrai problème.