Le processus de conception de produit est la séquence qu'une équipe suit pour transformer un problème de marché en un produit numérique fonctionnel. Le nôtre s'appelle le Product Design Process (PDP). Il se déroule en quatre phases (recherche, idéation, exécution et évaluation technique) divisées en douze étapes, chacune ayant un responsable désigné et un livrable dont dépend l'étape suivante.
Voyez cela comme une « mise en place ». Tout est coupé, mesuré et à portée de main avant même que la poêle ne s'approche du feu.
Cet article explique ce qu'est la conception de produit, pourquoi cette séquence est importante et ce qui se passe à chacune des douze étapes du processus. Il est destiné aux fondateurs, aux propriétaires de produits et aux cadres qui doivent décider du volume de travail de conception à financer avant d'écrire la moindre ligne de code.
Nous ne gardons pas cette méthode pour nous. Elle est publiée dans son intégralité, avec toutes les phases et des exemples concrets, dans notre livre sur le Product Design Process, écrit par trois des personnes qui l'ont conçu et mis en œuvre chez Imaginary Cloud. Ce qui suit est la version opérationnelle de cette méthode, celle-là même qui est à l'origine de notre conception de produits numériques.
| Phase | Étape | Responsable | Livrable |
|---|---|---|---|
| Recherche | 1. Briefing | Designer UX | Déclaration partagée de la vision, des objectifs et des exigences métiers |
| Recherche | 2. Recherche utilisateurs | Designer UX | Profil des utilisateurs cibles, objectifs et motivations |
| Recherche | 3. Benchmark de design | Designer UX | Panorama des produits concurrents et complémentaires |
| Idéation | 4. Parcours utilisateur | Designer UX avec Product Owner | Scénarios utilisateurs cartographiés et exigences produit |
| Idéation | 5. Matrice de décision | Product Owner avec Designer UX | Périmètre priorisé en fonction des contraintes de temps et de coûts |
| Idéation | 6. Wireframes | Designer UX | Structure des écrans et flux de navigation |
| Idéation | 7. Moodboard | Designer Produit | Style visuel et ambiance validés |
| Exécution | 8. Guide de style | Designer Produit | Palette de couleurs, typographies, style d'image, composants d'interface |
| Exécution | 9. Design d'interface (GUI) | Designer Produit | Écrans finaux, approuvés par les parties prenantes |
| Exécution | 10. Prototype | Designer Produit | Prototype interactif partageable |
| Évaluation technique | 11. Architecture globale | Lead technique | Conception technique et dépendances tierces |
| Évaluation technique | 12. Plan de projet | Lead technique avec Product Owner | Jalons, charge de travail et coût estimé par phase |
Le design produit consiste à définir ce qu'un produit doit faire, pour qui, et comment il doit se comporter, avant même sa conception. Dans le PDP, ce travail aboutit à douze livrables identifiés, allant du profil utilisateur au plan de projet chiffré. (Consultez notre courte définition du processus de design produit.)
Ce terme est souvent confondu avec le design industriel, qui concerne les biens produits en série : un iPhone, un grille-pain, une guitare ou une chaise. Cet article traite du design de produit numérique, qui en est un sous-ensemble. Un produit numérique est un bien immatériel disponible en ligne, comme un site web ou une application.
Le design se résume-t-il à l'apparence d'un produit ? Pas vraiment, non. L'esthétique compte, mais le design concerne avant tout le fonctionnement du produit.
Cette distinction a une conséquence pratique. Les étapes 1 à 7 du PDP, soit plus de la moitié du processus, ne produisent aucun design visuel. Elles génèrent un profil utilisateur, une analyse comparative, un parcours, un périmètre priorisé et une maquette fonctionnelle. Ce n'est qu'ensuite que l'on choisit les couleurs.
Le designer produit détermine quels utilisateurs le produit sert et ce qu'ils cherchent à accomplir, puis transforme ces besoins en une solution utilisable. La première étape du processus de design produit consiste à identifier les problèmes des utilisateurs finaux ; c'est pourquoi la recherche utilisateur constitue l'étape 2 du PDP et non la création d'écrans.
Savoir qui utilisera le produit est tout aussi important que de savoir quel problème il résout. Un même problème appelle une réponse différente selon la personne qui le rencontre.
Ce titre recouvre plusieurs fonctions. Un développeur UI, un designer UX, un designer d'interaction, un designer d'expérience et un prototypiste entrent tous dans la catégorie des designers produit. Chaque entreprise définit ces rôles différemment, c'est pourquoi le PDP désigne un responsable pour chaque étape plutôt que de se fier aux intitulés de poste.
Développer parfaitement le mauvais produit est ce qui coûte le plus cher à une équipe. C'est aussi le résultat le plus probable d'une approche non structurée.
Nous le savons par expérience. Les projets décrits ci-dessous ont été livrés dans les délais et selon les spécifications, mais ont échoué sur le marché car personne n'avait vérifié les attentes du marché avant de lancer le développement.
Le design permet de combler ce fossé. Bien le réaliser nécessite une analyse commerciale, des études utilisateurs, une compréhension des comportements réels et suffisamment de connaissances techniques pour distinguer une bonne idée d'une idée coûteuse.
L'inverse est tout aussi vrai. Une application peut reposer sur une idée brillante et échouer si la navigation déroute les utilisateurs, si l'expérience est laborieuse ou si l'outil est trop complexe. Une excellente idée ne restera qu'une idée si le design produit ne répond pas aux besoins des utilisateurs finaux.
Laissez-nous vous raconter un peu l'histoire d'Imaginary Cloud. En 2014, nous avons conçu un service appelé « The War Room ». La promesse était de réunir un product owner, un designer et une équipe de développement dans une même pièce pendant trois jours pour livrer un MVP (Produit Minimum Viable).
Les résultats étaient inégaux. Nous avons livré quelques projets, mais ils ont tous échoué lors de leur première confrontation au marché. L'époque du « construisez-le et ils viendront » était révolue depuis longtemps. Le Lean Startup et le Google Design Sprint étaient sur toutes les étagères et dans tous les favoris, mais aucune de ces méthodes ne suffisait à elle seule.
À ce moment-là, nous avons réalisé que les produits numériques nécessitent une recherche approfondie avant d'être développés. Comme aucun processus de design documenté ne nous convenait, nous en avons créé un : le Product Design Process (PDP).
Le PDP est un ensemble de techniques existantes, éprouvées par l'industrie au fil du temps et articulées entre elles pour rendre le flux de travail de l'équipe de design produit aussi efficace que possible.
À ce jour, notre Product Design Process reste au cœur de notre manière de concevoir des produits numériques, et c'est le processus qui sous-tend chaque projet de notre portfolio.
Le processus de conception de produit (PDP) est une démarche centrée sur l'utilisateur pour les produits numériques, adoptant une approche multidisciplinaire. Son objectif principal est de commercialiser les produits rapidement sans faire l'impasse sur les preuves qui doivent les étayer. Il est tout aussi efficace pour les projets visant la croissance par l'optimisation.
Notre vision est simple. Nous voulons offrir la meilleure solution possible à un problème spécifique, sur un marché où la plupart des produits concurrents sont lancés sans en proposer.
La première phase du PDP relève de la responsabilité du designer UX. L'objectif est de rassembler les preuves qui soutiendront chaque décision prise par la suite, afin qu'aucune ne repose sur de vagues suppositions. C'est à ce stade que les aspects principaux du modèle économique et les besoins des utilisateurs sont identifiés.
1. Briefing. Garantit que toute l'équipe est sur la même longueur d'onde et dispose de toutes les informations pertinentes : la vision et les objectifs du projet, ainsi que les exigences métier.
2. Recherche utilisateur. Le profil des utilisateurs est discuté avec les parties prenantes du produit. Définir le profil des utilisateurs cibles permet d'identifier leurs principaux objectifs et motivations. La recherche utilisateur garantit l'utilité et l'efficacité du produit du point de vue de l'utilisateur.
3. Benchmark de conception. L'équipe examine des produits similaires et complémentaires, les modèles de conception qu'ils utilisent et les technologies sous-jacentes. Cet examen montre où le nouveau produit peut se positionner sur le marché, quelles conventions les utilisateurs attendent déjà, et quelles fonctionnalités et décisions de conception le distingueront réellement.
L'idéation est au cœur du processus créatif. C'est là que le concept du produit est formulé en fonction des besoins de l'utilisateur et du modèle économique, tous deux identifiés lors de la phase de recherche. À ce stade, le designer UX, le designer produit et le product owner doivent travailler en étroite collaboration.
4. Parcours utilisateur. L'expérience utilisateur idéale est cartographiée en décrivant chaque action de l'utilisateur. Divers scénarios sont rédigés et validés. Cela offre une vision globale de l'expérience, garantissant cohérence et fluidité, et sert de base pour établir les exigences du produit.
5. Matrice de décision. La matrice de décision évalue chaque fonctionnalité candidate sur deux axes : son importance pour l'utilisateur et l'entreprise, et le temps et le coût nécessaires à sa réalisation. Ce qui survit à cette évaluation constitue le périmètre réalisable dans le respect des contraintes, au stade actuel de vie du produit. Ce qui ne survit pas est consigné plutôt qu'oublié.
6. Wireframes. C'est ici que l'ossature des écrans commence à être dessinée. La structure des pages et le flux de navigation sont définis, ce qui fixe l'emplacement de chaque élément de contenu avant toute mise en forme, et accélère le travail de design ultérieur.
7. Mood board. Garantit que l'apparence et la convivialité du produit reflètent l'expérience souhaitée et sont en phase avec le profil utilisateur et la stratégie de marché. Cette étape capture l'« atmosphère » du produit à travers une collection d'images, de mots et d'autres éléments visuels.
Lors de cette phase, le concepteur produit transforme le concept validé jusqu'ici en écrans que les utilisateurs peuvent réellement visualiser et parcourir.
8. Guide de style. C'est ici que l'interface graphique définit ses règles : palette de couleurs, polices, style des images, champs de saisie, boutons, etc. Fixer ces choix une fois pour toutes, dans un document unique, permet de garantir une cohérence visuelle entre chaque écran de l'application.
9. Conception de l'interface utilisateur graphique (GUI). Les écrans finaux sont réalisés en appliquant le guide de style aux wireframes. La neuvième étape permet aux parties prenantes de visualiser l'aspect définitif des écrans du produit afin de les valider avant le début de l'implémentation.
10. Prototype. Un prototype interactif est développé, accessible en ligne et partageable sur différents appareils et avec divers utilisateurs via un lien et un mot de passe. Il permet de naviguer d'un écran à l'autre, facilitant ainsi la collecte de retours, que ce soit auprès des parties prenantes, des utilisateurs potentiels ou des investisseurs.
L'objectif principal de cette phase est de garantir que chaque exigence et idée générée est réaliste à mettre en œuvre et réalisable dans les délais et le budget impartis.
11. Architecture de haut niveau. Cette étape développe la conception technique en trouvant le juste équilibre entre complexité et portée. C'est également ici que sont identifiées les dépendances externes liées à des fournisseurs tiers, tels que Stripe pour les paiements, Meta (Facebook) pour l'authentification, ou Amazon Web Services pour l'hébergement. Elle détaille la manière dont le produit sera construit, ainsi que les technologies et les compétences nécessaires à sa réalisation.
12. Plan de projet. La dernière étape définit les jalons majeurs et offre une vision globale de la structure du projet, de ses phases, de ses points de convergence et de ses interdépendances. Vous saurez ainsi comment concevoir le produit, l'effort nécessaire et les coûts prévus pour chaque phase.
Il est crucial de respecter l'ordre des phases énoncées. Les livrables des phases initiales sont indispensables au bon déroulement des étapes suivantes. Bien qu'il soit courant en design de mener plusieurs tâches de front, le faire entre différentes phases est contre-productif.
Suivre le PDP offre une série d'avantages par rapport aux approches non structurées. Cela réduit le temps et les coûts consacrés à la conception et au développement du produit, permet de planifier des calendriers réalistes et aboutit à un produit de meilleure qualité.
La raison réside dans une courbe de coûts bien documentée en économie du logiciel, bien qu'il soit utile d'être précis à ce sujet. L'étude évaluée par des pairs de Boehm et Basili a révélé qu'un problème détecté après la livraison peut coûter beaucoup plus cher à corriger qu'un problème identique détecté lors des phases d'exigences et de conception : pour les systèmes complexes à haute fiabilité, le coût peut être multiplié par 100 (Software Defect Reduction Top 10 List, IEEE Computer, 2001). Le multiplicateur exact est débattu et dépend fortement du système : les travaux ultérieurs de Boehm ont ramené ce ratio à environ 5:1 pour les petits projets agiles avec intégration continue, ce qui correspond davantage au profil de la plupart des produits numériques. La tendance, cependant, ne fait aucun doute : plus un problème de conception ou d'exigences est détecté tardivement, plus il coûte cher.
Le chiffre macroéconomique a été mis à jour depuis. L'étude de 2002 du National Institute of Standards and Technology des États-Unis évaluait le coût annuel d'une infrastructure de test logiciel inadéquate à environ 59,5 milliards de dollars. Vingt ans plus tard, le Consortium for Information and Software Quality (CISQ) a estimé le coût de la mauvaise qualité logicielle aux États-Unis à environ 2,41 billions de dollars en 2022, dont environ 1,52 billion correspond à de la dette technique accumulée (The Cost of Poor Software Quality in the US: A 2022 Report). La conclusion est la même, à une échelle bien plus vaste : il est toujours moins coûteux de prévenir les problèmes de qualité dès le début.
Les décisions de conception suivent la même logique. Modifier un wireframe prend une après-midi. Modifier cette même décision une fois l'interface construite et déployée coûte une version entière. Choisir de concevoir selon un processus plutôt que par improvisation permet de maintenir ces décisions dans la partie la moins coûteuse de la courbe.
Il est impossible de générer de bonnes idées sans comprendre le problème à résoudre. Et il est impossible d'exécuter sans comprendre ce qui doit être construit. Chaque fois qu'une nouvelle idée est prototypée sur la base d'exigences immatures, une grande partie du travail déjà accompli doit être repensée ou reconçue.
Forcer une refonte complète vous laissera, au mieux, avec un produit qui semble rapiécé plutôt que conçu comme un tout intégré. C'est pourquoi il est crucial de diviser le processus en phases et en étapes selon une séquence définie.
Respecter l'ordre des phases est essentiel, mais au sein de chaque étape, vous trouverez plusieurs tâches qui peuvent être menées simultanément. Cette flexibilité vous permet de vous adapter aux caractéristiques spécifiques de chaque projet et aux préférences de l'équipe sans compromettre la qualité du produit, les délais ou le budget.
Besoin de faire évoluer un produit existant ? Revenez en arrière et réexaminez les phases et étapes précédentes. Si de nouveaux retours doivent être intégrés dans un prototype, l'équipe doit revenir à ces étapes antérieures avant d'effectuer les changements. Apporter des modifications à la conception finale est toujours beaucoup plus coûteux que d'ajuster à chaque étape au fur et à mesure que les retours arrivent ; c'est pourquoi une bonne communication est le moteur de tout le processus.
Tout au long du processus, à chaque étape, il devrait y avoir au moins trois points de communication : un atelier initial ; un point d'étape à mi-parcours de l'exécution ; et une réunion finale pour valider l'étape.
Entre ces points de contrôle, l'équipe doit rester concentrée sur l'étape en cours, sans apports extérieurs susceptibles de provoquer des distractions inutiles. À chaque réunion, l'équipe doit toujours apporter une valeur ajoutée et recueillir des retours.
Dans la même optique, si le product owner n'est pas disponible pour le point d'étape à mi-parcours, l'équipe doit commencer les étapes restantes de la phase plutôt que de laisser le projet stagner. Une communication constante avec le product owner est une exigence critique pour le succès du PDP : c'est ce qui permet des cycles de feedback courts et, par conséquent, des temps d'exécution réduits.
Pour découvrir notre processus de conception de produit en action, consultez notre étude de cas TravelWifi. TravelWifi est une plateforme e-commerce proposant des solutions internet portables. Notre mission était de refléter visuellement la diversité des produits offerts par la plateforme et de répondre aux attentes des utilisateurs en les guidant à travers un parcours fluide et intuitif. Cette étude de cas détaille nos recherches, le travail d'interface et les fonctionnalités déployées.
Pour en savoir plus sur la manière dont nous appliquons notre processus de conception à nos projets, n'hésitez pas à visiter notre portfolio.
Une fois le PDP terminé et la première version lancée, le produit doit encore être amélioré en suivant un cycle de conception, de construction et d'apprentissage. Ces changements post-lancement diffèrent généralement de ceux identifiés lors du développement du prototype.
Il s'agit souvent de petits détails issus des retours utilisateurs, présentant un faible risque pour l'interface graphique existante. C'est là tout l'intérêt des douze étapes : la base est déjà établie, ce qui suit relève donc du perfectionnement plutôt que de la refonte.
La plupart des étapes ne nécessitent pas de connaissances préalables spécifiques, mais la maîtrise du PDP est facilitée par des recherches approfondies et la collecte d'un maximum de références. L'avantage majeur du PDP est de rendre évidente l'importance de chaque étape et de ses livrables, ce qui évite aux équipes de se précipiter dans les phases finales sans bases solides pour justifier leurs choix.
Le PDP est désormais un processus stable, bien qu'il ne soit jamais figé, car le design produit est en constante évolution. Nous continuerons à le mettre à jour si nécessaire, en intégrant de nouveaux outils et techniques pour en optimiser les performances globales.
Pour un produit numérique classique, les douze étapes du processus de conception s'étalent sur plusieurs semaines plutôt que sur plusieurs mois. La recherche et l'idéation sont généralement les phases les plus longues, car elles définissent les exigences dont dépendent toutes les étapes ultérieures. La durée dépend du nombre de parcours utilisateur prévus, et non du nombre d'écrans.
Le design UX couvre le comportement d'un produit pour son utilisateur : recherche, parcours, wireframes et utilisabilité. Le design de produit englobe tout cela, en plus du modèle économique, de l'interface visuelle et de la faisabilité technique des propositions. Dans le PDP, le design UX prend en charge la phase de recherche et une partie de l'idéation, tandis que le design de produit se concentre sur l'exécution.
Le coût dépend de l'envergure du projet, mais la comparaison pertinente n'est pas entre le design et l'absence de design, mais entre le design et les retouches ultérieures. L'étape 12 permet d'établir le coût prévisionnel de chaque phase avant le début de toute mise en œuvre, ce qui permet de discuter du budget sur la base de faits plutôt que d'estimations approximatives.
Pas sans en payer le prix. Le résultat de chaque étape sert d'entrée à la suivante : la recherche utilisateur alimente le parcours utilisateur, qui alimente la matrice de décision, laquelle alimente les wireframes. Sauter une étape revient à travailler sur des hypothèses, qui se transformeront en retouches coûteuses une fois l'interface développée.
Oui, au sein d'une même phase. Plusieurs étapes d'une même phase peuvent être menées simultanément pour s'adapter à la disponibilité de l'équipe. Ce qui ne peut pas être parallélisé, ce sont les phases elles-mêmes, car chacune dépend des livrables de la précédente.
Un designer UX dirige la recherche et l'idéation initiale, un designer de produit pilote l'exécution, un responsable technique effectue l'évaluation technique, et le product owner intervient à trois points de contrôle à chaque étape : un atelier initial, un point d'étape à mi-parcours et une réunion de validation.
Oui. Pour un produit déjà sur le marché, le processus commence à la phase correspondant à la décision que vous souhaitez revoir. L'ajout d'une fonctionnalité implique généralement de revenir au parcours utilisateur et à la matrice de décision. Une refonte nécessite souvent de revenir au benchmark de design et au mood board.
Douze, un par étape : un brief, une étude utilisateur, un benchmark de design, un parcours utilisateur, une matrice de décision, des wireframes, un mood board, un guide de style, des designs d'interface (GUI), un prototype cliquable, une architecture de haut niveau et un plan de projet avec jalons et coûts.
Si vous vous demandez quel budget allouer au design avant de lancer le développement, nous serons ravis d'analyser votre produit à l'aune de notre PDP pour vous indiquer les phases les plus déterminantes. Contactez-nous ou découvrez-en plus sur nos prestations de design de produit numérique et de développement d'applications web .
Vous pouvez également consulter l'intégralité de notre méthodologie dans notre livre Product Design Process. Il détaille chaque phase avec des exemples concrets et les livrables attendus à chaque étape. Vous pouvez le commander directement sur Amazon.
Gestionnaire de contenu, éditeur de texte et présentateur d'idées stratégiques, tout en étant un fervent amateur des arts cinématographiques et de la narration visuelle.
Stagiaire en marketing avec un intérêt particulier pour la technologie et la recherche. Pendant mon temps libre, je joue au volley-ball et je gâte mon chien autant que possible.
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
