Le design thinking pose le problème et éprouve la solution. L'Agile la construit et la met en ligne. La charnière entre les deux est un QAP, qui choisit les fonctionnalités et les stories du MVP. Selon votre configuration, je prends la chaîne entière ou le segment qui vous manque : mon parcours me permet d'entrer en début de chaîne, en fin de chaîne, ou de rester du premier atelier à la disponibilité générale.
Quatre phases, deux méthodologies, trois horizons de roadmap. Les durées sont celles d'une fonctionnalité isolée, puis celles d'un produit complexe.
Le schéma se fait glisser latéralement.
En cuivre, ce que je livre moi-même. Les autres lignes situent la partie prenante qui intervient à ce moment.
Identifier, capturer et prioriser
Comprendre et cadrer le problème
Éprouver la valeur, la viabilité et la faisabilité
Recueillir le retour d'une cohorte choisie et corriger
Déployer et corriger les problèmes à l'échelle
Maximiser le retour sur investissement
Identifier, capturer et prioriser les opportunités. En continu, sans attendre le lancement d'un projet.
Deux diamants. Le problème d'abord : recherche, puis définition. La solution ensuite : idéation, puis validation. On en sort avec un problème cadré et une solution éprouvée sur sa valeur, sa viabilité et sa faisabilité.
Charnière entre les deux méthodologies : un QAP, planification agile trimestrielle, choisit les fonctionnalités et les stories nécessaires au MVP. Les sprints partent de là. Je livre le design system, les composants et les pages, et je suis le story mapping story par story.
Bêta privée, bêta publique, disponibilité générale. Puis l'amélioration continue, le moment où le retour sur investissement se fait, et la phase que la plupart des missions de design ne couvrent pas.
Trois pratiques qui séparent une mission d'une prestation de design classique : chaque story est notée sur une grille explicite avant de passer, tout est rendu dans un document qui s'ouvre, et le prototype est un vrai front-end.
Chaque story sort du story mapping sous forme de prototype, testé avec de vrais utilisateurs du client et noté. Sous la cible, la story repart en itération. Elle ne passe pas tant que la cible n'est pas atteinte.
L'intérêt d'une note dépasse le design : elle se présente en comité de direction, se compare d'une itération à l'autre, et se défend devant quelqu'un qui n'était pas dans la salle.
L'échelle est explicitée aux participants avant de commencer : 1 inutile ou incompréhensible, 2 manque de clarté, 3 fonctionne mais perfectible, 4 répond aux attentes, 5 intuitif, utile, rassurant. Sans cette explication, deux participants ne notent pas la même chose.
Tout ce qui précède est rendu dans un document unique. Il ouvre ce qu'il y a derrière chaque hypothèse : la recherche qui l'a produite, le test qui l'a éprouvée, la note qu'elle a obtenue.
C'est ce qui permet à un comité de direction de creuser n'importe quel point, des semaines après la présentation, sans avoir à redemander. Et c'est ce qui aligne les parties prenantes sur la valeur réelle de ce qu'on va offrir aux utilisateurs : une proposition de valeur qui n'est écrite nulle part se lit différemment dans chaque service.
À la place de la maquette cliquable, un vrai front-end branché sur une base de données de test. Le produit final, responsive et adaptatif : on parcourt tout, seules les données sont fausses.
Conséquence sur le test : le client utilise au lieu d'imaginer. Et sur le planning : le front-end livré en test est celui qui part en production.
Vingt-huit livrables, dans les quatre temps du double diamant. L'enchaînement est le même d'une mission à l'autre ; seule la profondeur varie.
Trois missions, trois lectures de la même méthode : une banque, le courrier industriel, l'IoT industriel.