Enregistrer le produit X - Une étude de cas sur le Design Thinking

Qu'est-ce que le Design Thinking ?

Imaginez que vous avez une idée. Vous proposez une application ingénieuse qui, selon vous, résoudra les problèmes de votre entreprise. Il n'existe actuellement aucune solution identique sur le marché et celle qui s'en rapproche le plus ne fonctionne pas vraiment comme les clients l'attendent.

Alors que votre vision est encore fraîche, vous commencez à penser à la première question fondamentale qui vous vient à l'esprit : "Combien de temps cela prendra-t-il pour le faire ?"

Et comme on se retrouve rarement avec un budget et un temps illimités, la deuxième question conséquente vient vite : « Combien ça va me coûter de le faire ?

Ces deux questions sont fondamentales et cruciales dans la fabrication d'un produit, mais souvent ce sont précisément les mauvaises questions pour commencer.

Au lieu de cela, la question la plus importante à poser en premier est : « Quelle valeur puis-je créer pour mes utilisateurs ? »

Pour mieux comprendre la portée d'un projet, les exigences et le calendrier, nous pouvons utiliser une méthodologie appelée "Design Thinking", qui nous aide pendant la "phase de découverte" d'un produit. C'est exactement le moment où nous devons comprendre non seulement ce qui fera un excellent produit, mais aussi comment et si nous devons le faire. Cette approche créative et expérimentale nous aide à mieux comprendre comment créer des choses non seulement utilisables mais surtout utiles.

Le processus de Design Thinking est particulièrement utile car il génère un résultat unique et spécifique : la connaissance.

Cette méthodologie a un champ d'utilisation plus large, mais dans le cadre de cette étude de cas sur le Design Thinking, nous nous concentrerons uniquement sur un domaine spécifique - le développement de produits logiciels.

La théorie du Design Thinking

Avant de nous plonger dans les applications pratiques du Design Thinking et mon expérience de son application, examinons plus en détail le processus de Design Thinking.

Le Design Thinking est une méthodologie qui fournit une approche basée sur les solutions pour résoudre les problèmes. Il se concentre sur la compréhension du point de vue de l'utilisateur, avec un point de vue centré sur l'humain. La puissance de cette méthodologie est la possibilité de tester rapidement si une idée, une solution ou une amélioration peut apporter des résultats concrets à nos clients. Intégrant différentes méthodologies, outils et techniques provenant de différents domaines (marketing, psychologie, design, business), le Design Thinking a pour but de placer l'utilisateur au centre même du problème que nous avons à résoudre.

Le but de la méthodologie est de "trouver l'utilisateur lui-même et de définir ses besoins" et en trouvant ces besoins, créer une solution ou un produit qui peut être vraiment utile. Pour atteindre cet objectif, l'ensemble du concept est divisé en six phases de réflexion sur le design.

1. Faire preuve d' empathie : l'objectif de cette phase est de comprendre votre client, en recherchant et en rassemblant des informations sur son entreprise. Au cours de cette phase, nous pouvons utiliser plusieurs outils différents, tels que des entretiens, des groupes de discussion, des observations et des enquêtes.
2. Définir : dans cette phase, nous collectons et catégorisons les informations de la phase d'empathie. C'est ici que nous définissons les User Personas et les User Journeys.
3. Idée : En utilisant les informations ci-dessus, l'équipe imagine ici des solutions. Il n'y a pas d'idées idiotes ou fausses ! Tout doit être exprimé et documenté.
4. Prototype : Au cours de cette phase, quelque chose de tangible est créé, qui vous permettra de vérifier votre idée dans la vraie vie. Ne compliquez pas trop et créez ce MVP le plus rapidement possible.
5. Test : Vérifiez votre idée dans la vraie vie avec des utilisateurs réels. Avoir un retour. Posez des questions sur la façon de l'améliorer.
6. Mettre en œuvre : il s'agit de la phase où toutes les connaissances collectées sont traduites en un produit final.

Si après avoir lu ceci, vous pensez peut-être : "C'est génial, mais comment cela va-t-il m'aider à faire rapidement de mon application une réalité ?" Afin de rendre cela plus tangible, je vais reprendre une étude de cas tirée de mon expérience personnelle qui a bénéficié du processus de design thinking.

Design Thinking appliqué - Une étude de cas réel

Introduction : Projet X

Il y a quelque temps, je me suis retrouvé à une réunion avec un entrepreneur, quelques managers et de nombreuses idées circulaient dans la salle. Leur concurrent direct avait récemment sorti une nouvelle application et la tension était palpable. L'entreprise voulait sortir quelque chose de nouveau sur le marché, pour éviter de perdre du terrain face à son concurrent.

Ils ont préparé un document avec certaines exigences, une vague idée de ce à quoi le produit devrait ressembler et combien devrait-il coûter.

"Nous devons suivre ce que les autres ont fait, avec un prix inférieur", a déclaré le directeur marketing. "Nous devons créer un système plus utilisable, qui simplifie le parcours de l'utilisateur", a ajouté un autre responsable. "Nous devons changer la façon dont nous collectons les informations, les simplifier et intégrer nos processus avec des tiers", a déclaré un autre. « Cela nous prendra des mois », secoua la tête le responsable technique, qui traduisit mentalement toutes ces demandes en centaines d'heures de code à implémenter.

Bien que je ne puisse pas divulguer tous les détails du projet, je peux divulguer que le produit était un logiciel de communication central. Ce logiciel gérait différents canaux (email vers SMS, fax vers VoIP) et il a été créé pour les plateformes web et mobiles. Le produit a été créé à l'origine quelques années auparavant, mais sa convivialité était médiocre. Au moment du lancement, le concurrent était loin devant en termes d'expérience utilisateur. De plus, ils avaient une excellente application mobile, qui gagnait du terrain dans la boutique d'applications mobiles.

La société X était une entreprise traditionnelle axée sur les processus, familière avec les projets traditionnels. Il avait exécuté quelques projets Agile dans le passé, mais il était nouveau dans l'idée de créer un MVP et de le tester sur le marché. Plus particulièrement, ils craignaient l'inconnu. Et si le nouveau MVP avait un effet indésirable ou imprévisible sur sa clientèle d'utilisateurs ? Ce manque de contrôle n'inspirait pas confiance.

La réunion décrite ci-dessus et les suivantes n'ont pas abouti à une définition claire de ce qu'était réellement le produit à atteindre. Nous savions seulement que nous devions atteindre la cible le plus tôt possible.

Cependant, à mesure que le projet avançait et qu'un concurrent commençait à gagner du terrain, le consentement de l'entreprise se solidifiait. La plupart étaient d'accord avec l'idée que : "Nous ne pouvons pas nous permettre de lancer un produit à moitié fini, nous avons besoin d'un produit qui fonctionne dès le départ."

Malgré une certaine perplexité et peur initiales, c'était l'occasion d'apprendre ce qui apporterait une réelle valeur à leur base d'utilisateurs et pourrait potentiellement attirer plus d'utilisateurs en créant un produit léger et rationalisé.

Cela a incité l'entreprise à rechercher des approches qu'elle n'avait jamais essayées auparavant, afin d'avoir un produit complet construit à temps, même s'il n'aura que des fonctionnalités essentielles à son lancement. Nous avons décidé d'utiliser le processus de Design Thinking et de nous concentrer sur les choses qui apporteraient vraiment de la valeur à l'utilisateur final et donc de battre la concurrence en n'apportant que ce qui est nécessaire au client.

Étape 1 - Empathie

Phase d'empathie : l'objectif de cette phase est de comprendre votre client, en recherchant et en rassemblant des informations sur son entreprise. Au cours de cette phase, nous pouvons utiliser plusieurs outils différents, tels que des entretiens, des groupes de discussion, des observations et des enquêtes.

Au sens le plus littéral, l'empathie est la capacité de comprendre et de partager les émotions des autres. Dans le design thinking, l'empathie est une "compréhension profonde des problèmes et des réalités des personnes pour lesquelles vous concevez".

Notre première étape a été de nous assurer que l'opinion de la personne la mieux payée (autrement connue sous le nom de HiPPO) ne prévalait pas sur celle des autres. C'est pourquoi, en collaboration avec les managers et le fondateur, nous avons compilé une liste des parties prenantes possibles à impliquer dans le processus de prise de décision.

Lors d'une réunion d'une journée, nous avons compilé la première liste de 30 noms (entre employés, responsables fonctionnels et clients) qui pouvaient être contactés directement, puis nous avons également sélectionné un public cible de 4 000 clients (environ 10 % de leurs clients récurrents utilisateurs base).

Nous avons essayé de « normaliser » notre clientèle cible autant que possible, en incluant la diversité en termes de répartition par sexe, d'industrie et d'autres points de données. Pour ajouter un niveau de complexité supplémentaire, l'emplacement physique de l'échantillon à interroger a tous été divisé en différentes villes et, dans certains cas, en pays. Nous avions maintenant des points de contact pour réaliser des entretiens et des questionnaires.

Le groupe a été organisé pour réaliser les entretiens à distance, en suivant une série de questions scénarisées et quelques règles de base :

• Pendant l'entretien, essayez d'utiliser la technique des « 5 pourquoi ».
• Essayez de comprendre le principal « quoi, comment, pourquoi » derrière chaque comportement.
• Assurez-vous que la personne interrogée utilise une webcam et qu'elle est suffisamment éloignée de la caméra pour pouvoir inclure au moins partiellement le langage corporel.
• Enregistrez toutes les interviews, au cas où elles auraient besoin d'être vues à l'avenir.

Nous avons préparé nos questions d'entrevue avec l'intention de comprendre quelles fonctionnalités principales devraient être améliorées ou éliminées, de sorte que nous puissions rapidement créer une nouvelle version répondant aux besoins de nos utilisateurs.

Pour le deuxième groupe d'utilisateurs, nous avons préparé une série de questions dans un formulaire Google. Nous avons opté pour des questions à choix multiples, avec quelques questions ouvertes formulées pour faciliter plus d'interaction de la part des utilisateurs, y compris une question demandant à l'utilisateur d'essayer la nouvelle version du produit qui vient d'être disponible en version bêta fermée.

Pour organiser l'ensemble du processus de collecte d'informations, nous avons utilisé des outils à distance qui ont permis à l'équipe de collecter des informations plus facilement, notamment Skype, Zoom, Google Forms et un tableau Kanban numérique où nous avons mis toutes nos activités et suivi leur statut.

Les premiers résultats des entrevues ont été encourageants, car les personnes interrogées étaient disposées à donner leur avis sur les faiblesses et les forces du système.

Cependant, le premier lot de réponses au questionnaire était beaucoup moins excitant : sur les 300 e-mails envoyés, seules 5 personnes ont rempli leurs questionnaires.

Déçus par ce résultat, nous étions prêts à essayer de nouvelles façons d'impliquer la base d'utilisateurs, quand l'un des responsables commerciaux nous a proposé une idée :

« Je ne pense pas qu'ils répondront à des e-mails, ils n'ont pas l'habitude d'interagir avec nous. Mais, si nous communiquons avec tous ceux qui ont un renouvellement expirant et leur donnons une petite incitation, je suis sûr qu'ils nous donneront un coup de main.

L'idée était simple mais exceptionnelle. En quelques heures, nous avons eu une nouvelle liste d'utilisateurs (3800), qui maintenait la même division entre le grand public et les extrêmes. Or, ces utilisateurs seraient « obligés » d'interagir avec le système, du fait de la proximité de leur renouvellement.

Cette fois-ci, on leur a demandé de répondre à une série de questions, de participer à la bêta et en retour, d'obtenir une remise sur le renouvellement. L'adhésion a été complète et à la première livraison de ce nouveau modèle, plus de 70% des utilisateurs ont répondu et complété le questionnaire.

Après avoir itéré et modifié certaines des questions, et grâce à certains utilisateurs désireux d'interviewer plus d'une fois, nous étions prêts à définir plus clairement notre base d'utilisateurs.

Étape 2 - Définir

Étape de définition : dans cette phase, nous recueillons et catégorisons les informations de la phase d'empathie. C'est ici que nous définissons les User Personas et les User Journeys.

Le sens du dictionnaire de définir est de déterminer l'identité et les qualités essentielles d'une notion . Dans notre cas, nous avons voulu définir les éléments suivants :

• nos clients idéaux
• leurs problèmes
• les solutions à leurs problèmes
• les besoins et les craintes de nos clients auxquels nous avons dû répondre

En termes de réflexion conceptuelle, la phase de définition est l'endroit où vous analysez vos observations et les synthétisez en problèmes fondamentaux que vous avez identifiés.

Nous avions une base de données suffisante pour comprendre quels étaient les vrais problèmes. En plus des commentaires reçus lors de la phase d'empathie, il contenait des points qui avaient été mis en évidence par les employés de la société X mais qui n'avaient jamais été signalés à la direction, ainsi que des forces, des faiblesses et d'autres problèmes qui n'avaient jamais été pris en compte.

L'action suivante consistait à créer nos User Personas. Lors de cette phase de brainstorming, nous avons impliqué toute l'équipe élargie. La phase de brainstorming a toujours été effectuée à distance, en utilisant des systèmes et des outils de visioconférence pour suivre les personas et leur création en temps réel.

Pour chaque Persona, nous avons identifié sa biographie, son approche de la technologie, son utilisation des médias sociaux, ses marques préférées, ses besoins et ses idées et spéculé sur ce qu'aurait été son Customer Journey.

Après cela, nous avions sélectionné les User Personas du client commun et disposions d'un ensemble fini de données provenant d'entretiens et d'enquêtes. C'était le bon moment pour se salir les mains.

Lors de la phase de définition, nous avons essayé de transformer une définition générique d'un problème du type « Nous avons besoin d'un produit qui augmentera nos ventes de 10 % » en une solution plus spécifique du type : « Hommes et femmes adultes, entre 35 et 45 ans qui travaillent dans un bureau doivent recevoir des communications ayant une validité légale pour être sûrs que l'expéditeur est bien celui qu'ils prétendent être.

À ce stade du processus de projet, nous avions terminé des séances de remue-méninges autour de nos utilisateurs, émis des hypothèses de solutions et gardé l'esprit ouvert à toutes les innovations possibles. "La seule idée stupide est celle qui n'est jamais exprimée" était le mantra.

En peu de temps, sachant qui étaient nos sujets, nous avions une vision claire de ce qui était utile à nos utilisateurs, ainsi que des besoins et des craintes auxquels nous devions répondre tout au long du parcours client.

Nous nous sommes ensuite engagés dans la construction d'une "User Story Map", qui nous a permis de catégoriser le processus des utilisateurs, en cartographiant les thèmes. Pour chacun des personnages, nous avons défini l'ensemble d'activités, d'histoires et de tâches que nous supposons qu'ils doivent accomplir pendant le voyage. Ce faisant, nous avons pu tester rapidement notre idée et comprendre si elle répondait aux besoins fondamentaux. Si c'était le cas, nous pourrions le mettre sur le marché plus rapidement que tout le monde, ce qui était essentiel car notre concurrent rencontrait chaque jour plus de succès.

Étape 3 - Idée

Phase d'idéation : En utilisant les informations ci-dessus, l'équipe imagine ici des solutions. Il n'y a pas d'idées idiotes ou fausses ! Tout doit être exprimé et documenté.

Une étape plus loin de la définition est la phase d'idéation, où la clé est de former des concepts et des solutions réels, pas seulement des définitions abstraites.

En termes de réflexion conceptuelle, l'idéation est "le processus par lequel vous générez des idées et des solutions à travers des sessions telles que l'esquisse, le prototypage, le brainstorming, l'écriture de cerveau, la pire idée possible et une multitude d'autres techniques d'idéation".

Notre équipe était complètement distante, nous avons donc décidé de travailler de manière Lean lors de la production et de la révision des documents. Par exemple, les designers et autres membres de l'équipe ont convenu que pour être le plus rapide possible, la meilleure solution serait de commencer par des dessins sur papier et d'en partager les photos dans le groupe. Ce n'est qu'alors que nous produirons les designs les plus intéressants en Balsamiq ou Axure.

Pour chaque croquis réalisé, nous avons recueilli des informations auprès des utilisateurs, nous avons défini un ensemble de solutions et nous sommes revenus vers ces utilisateurs (quand c'était possible et aussi souvent que possible) pour tester avec eux le processus et le résultat.

Étape 4 - Prototypage

Phase de prototypage : _ Au cours de cette phase, quelque chose de tangible est créé, qui vous permettra de vérifier votre idée dans la vraie vie. Ne compliquez pas trop et créez ce MVP le plus rapidement possible. _

Pendant la phase de prototype, il était enfin temps de donner vie à nos définitions et à nos idées. Un prototype est le premier modèle original d'un produit proposé, et c'est exactement ce que nous avons décidé de construire. Selon les normes de conception, l'étape du prototype est l'endroit où vous créez des versions réduites et peu coûteuses du produit réel pour étudier les solutions des étapes précédentes.

Après presque 10 jours depuis le début de notre voyage, nous sommes arrivés au moment crucial, une réunion avec une équipe de développeurs où nous avons eu l'occasion de vérifier nos hypothèses et estimations. Après une session de consultation et de définition avec l'équipe de développeurs, nous avons pesé les histoires et compris que l'effort majeur du travail de développement sera dans le développement du système back-end et l'interfaçage avec les systèmes hérités actuellement en place. Parallèlement à cela, nous avons également réalisé que la création des systèmes frontaux serait un exercice beaucoup plus court. Ainsi, nous avons décidé de créer un prototype frontal en utilisant les composants qui existaient déjà dans le système pour gagner du temps.

Nous avions un délai de 3 jours pour avoir une première version du prototype prête. Ce prototype devait refléter au maximum le produit et conserver les fonctionnalités nécessaires.

Après 3 jours, nous avions notre première version du prototype prête. Il contenait de « fausses » données qui reflétaient le comportement du logiciel que nous voulions créer. Certains éléments accessoires manquaient, mais le logiciel dans cet état représentait visuellement un bon pourcentage du contenu total prévu.

Au bout de deux semaines de travail, nous avions un logiciel que nous pouvions essayer et tester avec de vrais utilisateurs. Nous avons utilisé un logiciel de surveillance de l'expérience utilisateur pour analyser les cartes thermiques et l'attention des utilisateurs pendant qu'ils naviguaient dans notre prototype.

Étape 5 - Essai

Phase de test - Vérifiez votre idée dans la vraie vie avec des utilisateurs réels. Avoir un retour. Posez des questions sur la façon de l'améliorer.

Après une phase de définition, d'idéation et de prototype, il était enfin temps de voir si notre produit fonctionnait réellement dans la vraie vie. En termes de design thinking, tester signifie mettre à l'essai le produit complet en utilisant les meilleures solutions créées lors de la phase de prototypage.

Dans notre cas, la phase de test n'a pas seulement eu lieu à la fin, mais c'était une boucle constante de rétroaction et d'itération chaque fois que cela était possible. A la fin de chaque étape accomplie, nous avons essayé d'avoir des retours d'utilisateurs ou de clients, avant de nous convaincre de passer à la phase suivante.

Une fois le prototype terminé, il était temps de le tester auprès du public le plus large possible et de vérifier avec eux dans quelle mesure il répondait efficacement à leurs besoins, de comprendre leur perception et de comprendre s'il atteignait leurs objectifs.

La phase de test comprenait spécifiquement un prototype de procédure pas à pas où les utilisateurs pouvaient voir le nouveau flux de travail et effectuer des actions, ainsi que quelques sessions où l'équipe observait directement les utilisateurs, tout en suivant leurs réponses. Un questionnaire simple a été utilisé pour collecter les taux de conversion sur des fonctionnalités spécifiques de la plate-forme, où les utilisateurs ont été invités à noter le processus de 1 à 10.

La phase de test a ensuite été étendue à toute l'équipe et même à certaines personnes extérieures à l'organisation (clients et utilisateurs) qui, lors des sessions précédentes, avaient volontairement consenti à donner leur avis sur la mise en place du système.

Les résultats de ces tests ont été encourageants. Les parties prenantes de la société X ont pu non seulement voir les maquettes mais essayer et « toucher » le produit pour la toute première fois. L'équipe élargie a eu l'occasion de tester et de vérifier ses hypothèses et de les corriger au fil du temps dans un délai de deux semaines.

Maintenant, le test final attendait : l'ouvrir aux utilisateurs et comprendre ce qui allait se passer ensuite.

Étape 6 - Mettre en œuvre

Phase de mise en œuvre : C'est la phase où toutes les connaissances collectées sont traduites en un produit final.

Nous avions des données, des idées, des personnalités et notre premier prototype tangible. Il était temps de retrousser nos manches et de commencer à développer. Nous avions un mois et demi pour mettre en place notre nouveau système.

Nous avons défini un ensemble de règles pour que notre MVP soit implémenté en peu de temps :

• Nous ne construirons que ce que nous avions défini, sans ajouter de nouvelles fonctionnalités.
• Nous nous concentrerons sur l'objectif principal de l'entreprise.
• Nous utiliserons des méthodologies agiles au sein des équipes pour gérer la charge de travail.

Pour terminer le projet à temps, nous avons recruté quelques nouveaux membres de l'équipe qui n'avaient pas été impliqués dans le projet depuis les toutes premières étapes de la phase de découverte.

Nous avons ajouté des développeurs frontend, des développeurs backend et des concepteurs. Les nouveaux membres de l'équipe travaillaient à distance et il n'était pas possible de tous les réunir dans la même pièce pendant la durée du projet, nous nous sommes donc assurés d'avoir les bons outils pour maintenir la communication.

Le processus mis en place pour gérer le travail était Agile. Nous avons divisé le temps restant en plusieurs sprints courts, avec des réunions à distance tous les jours et des mises à jour via Slack dans la journée pour échanger les idées et s'entraider pour résoudre les problèmes.

Nous n'avions pas de documentation complète stockée quelque part, mais mentalement, nous avions tous un ensemble complet d'actions, une vision commune partagée et des objectifs au sein de l'équipe. Nous avons tous commencé à percevoir les User Personas comme un véritable utilisateur, avec ses propres besoins et problèmes. Une fois que notre équipe a commencé à avoir une vision alignée, nous sommes passés à la définition de ce qui devait être fait et quand afin de terminer le projet à temps.

Les activités ont été décrites dans une User Story Map, afin de conserver la preuve originale des personas et du flux que nous voulons donner au produit.

Les cartes User Story ont été créées en trois étapes claires : identifier les activités, identifier les étapes nécessaires pour terminer l'activité et la liste des histoires/tâches associées à chacune. Nous avons trié les histoires en fonction de la priorité (doit, devrait, pourrait), ce qui a dicté quels composants ont été intégrés au produit.

L'équipe a pu procéder à un rythme rapide depuis le tout début de la mise en œuvre, grâce à une vision claire partagée par l'équipe, et par la méthode que nous avons employée qui a permis à l'équipe de rester sur la bonne voie sans pilotage direct de la direction au-dessus. Tous ceux qui travaillaient sur le projet avaient en tête des questions issues des étapes du Design Thinking :

• Quelle action chaque utilisateur de notre plateforme devrait-il effectuer et qu'essayait-il d'accomplir ?
• Quelles étapes ces utilisateurs doivent-ils suivre pour atteindre l'objectif final ?
• Quels points douloureux avaient-ils auparavant et comment devrions-nous les éviter ?

Cela a permis à notre équipe de prendre ses propres micro-décisions et d'orienter le produit vers son objectif final.

Nous avons fait deux revues du travail en cours à la fin de chaque sprint et une revue de version finale à la fin du parcours, avant que le produit ne soit finalement mis en production. Nous avons utilisé le dernier sprint pour préparer l'infrastructure nécessaire à l'exécution et au lancement du produit.

Enfin, les utilisateurs qui ont utilisé notre ancien produit ont été à nouveau invités à essayer la nouvelle version. Notre produit est sorti en production deux mois après la réunion au cours de laquelle l'idée de le fabriquer a été exprimée. Le produit a fonctionné, les utilisateurs ont commencé à l'utiliser et nous avons progressivement envoyé plus de nouveaux utilisateurs vers cet outil au lieu de l'ancien. Les tests A/B nous ont montré qu'ils préféraient le nouveau produit, et le projet a été accepté par l'entreprise comme un grand succès.

Plus important encore, une méthodologie de Design Thinking a finalement été acceptée. Nous pensons que cela aura un impact positif et durable et leur permettra de créer de meilleurs produits à l'avenir.

Conclusion

Tout au long de cette étude de cas, nous avons montré comment la méthodologie du Design Thinking peut être appliquée à un problème réel avec un temps et un budget limités.

Au lieu d'utiliser des approches plus traditionnelles et de produire des choses en étapes séquentielles, nous avons choisi d'itérer à travers les six étapes du design thinking. Faites preuve d'empathie. Définir. Idée. Prototype. Test. Mettre en œuvre. Cela est devenu notre mantra et nous a permis de produire un produit très bien reçu.

L'utilisation du Design Thinking a permis de gagner du temps et, par conséquent, de réduire les coûts consacrés au projet. Nous ne travaillions pas sur des millions de fonctionnalités différentes, mais seulement sur quelques actions bien pensées et claires pour tous les membres de l'équipe. Plus important encore, nous avons pu fournir le produit et la valeur dont les utilisateurs avaient besoin.

L'utilisation du processus de Design Thinking nous a aidés dans de nombreux domaines différents :

• Du point de vue de la gestion de projet, cela nous a permis de définir clairement la portée du projet et d'éviter la dérive de la portée.
• Du point de vue commercial, cela nous a permis de sélectionner les fonctionnalités qui apportent une réelle valeur ajoutée à l'entreprise.
• Du point de vue du développement, cela nous a aidés à voir clairement l'objectif de ce que nous devons construire avant même de commencer à le construire.
• Du point de vue de l'équipe, cela a impliqué tous les membres de l'équipe et leur a permis de travailler efficacement ensemble et de faire entendre leur opinion à chaque étape du processus.

Lorsque nous avons commencé le processus de Design Thinking, le client a été accueilli avec scepticisme, mais lorsque nous avons terminé et obtenu les commentaires de nos clients, il était immédiatement clair que les étapes que nous avons définies nous ont aidés à réaliser quelque chose qui aurait été très difficile ou difficile. impossible autrement. Cela a été apprécié par le client et est devenu leur projet phare interne pour les futurs défis à venir.