Utiliser le Design Thinking pour arreter de construire des logiciels sans valeur

C’est le titre de la conférence donnée par Jeff Patton au QCon London 2011 !

Jeff Patton commence par exposer les faits.

• Typiquement de 50% à 80% des logiciels que nous livrons échouent à atteindre leur objectif.
• Pour quatre projets qui entrent en développement, seulement un arrive sur le marché.
• Au lancement, au moins un produit sur trois échoue malgré l’étude et la planification.
• Selon le Standish Group, 64% des fonctionnalités sont rarement ou jamais utilisées.
• Ce n’est seulement qu’après la livraison que la valeur d’un produit apparait. Par exemple il compare la différence de valeur entre les backlogs (Ensemble des fonctionnalités d’un produit selon la méthodologie Agile Scrum) de l’iPod et du Zune (un des gros échecs de Microsoft).
• Délivrer des logiciels stupides rapidement ne fait que donner plus de logiciels stupides. Il faut donner du sens à ce que nous développons.

Ayant connu de nombreux projets, je ne peux qu’approuver ce constat qui est à la fois un problème pour l’entreprise mais aussi pour la motivation du développeur. C’est pour ça que j’ai très vite compris l’intérêt des visions de l’expérience utilisateur et du design thinking.

Pour Jeff Patton, il faut se concentrer sur les fonctionnalités qui ont du sens voire qui vont changer dans le monde quand le logiciel sera livré. Le but est de minimiser la sortie en maximisant les résultats.

La recherche et l’analyse donne le sens de l’état actuel des choses. Le design imagine le monde différemment de ce qu’il est actuellement.

Il présente ensuite sa façon d’améliorer ce constat selon une méthode itérative qui se base sur quatre étapes :

• comprendre le problème
• identifier des solutions (générer un maximum d’idées !)
• affiner et valider (itérer !)
• créer un plan

Etapes de Design Thinking

Comprendre le problème

C’est apprendre et non seulement recueillir des besoins. Il faut demander aux utilisateurs de raconter des histoires, laisser l’utilisateur vous apprendre leur métier et ensuite donner du sens à ce que l’équipe a apprise.

Représenter les idées permet d’être sûr qu’on s’est bien compris. A travers une discussion et la construction itérative de modèles, on arrive à une compréhension forte et commune. L’idée est donc de résoudre le problème ensemble (comme les pratiques Agiles essayent de mettre en avant).

Il faut aussi régler le problème dans son contexte.

Générer un maximum d’idées pour identifier des solutions

Il faut générer un maximum d’idées, les combiner, etc. Utiliser un tableau pour y dessiner des esquisses est une façon collaborative de générer des idées d’interfaces utilisateurs.

On peut aussi travailler des esquisses individuellement puis ensuite partager ces idées.

Partager les idées générer par le Design Thinking

Itérer pour affiner et valider les solutions

L’itération pour un Agiliste c’est incrémenter ou construire petit à petit. Pour un designer, cela correspond plus à construire une version simple, la valider puis améliorer lentement la qualité et les fonctionnalités.

Il est utile de valider les concepts avec des prototypes (du papiers, des crayons et des ciseaux suffissent), les tester si possible avec de réels utilisateurs en simulant leurs utilisations.

Prototypage dans le cadre du Design Thinking

Planifier pour continuer à apprendre pendant que vous livrez.

Votre plan nécessite des livraisons publiques et privées. Chaque livraison est une opportunité d’apprendre et d’identifier la valeur. Utiliser un développement itératif et incrémental permet de réduire le risque.

Planification liée au Design Thinking

Il fait au passage référence au challenge des marshmallows de TED pour prouver ce concept.

L’outil appellé Story Map raconte l’histoire de votre produit ainsi que son planning de sortie incrémental. Cette Story Map permet d’associer les sorties (la productivité) avec les résultats (la rentabilité).

Ma conclusion est que le Design Thinking associe Expérience utilisateur et Agilité. Il va plus loin que l’agilité car il y associe les principes d’expérience utilisateur pour définir les besoins réels : ceux qui vont assurer le succès d’un logiciel.

Mais la question est-ce que le Design Thinking est envisageable dans le contexte d’une grande partie des entreprises ?