En tant que chef de produit concerné, vous vous êtes probablement posé la question à un moment donné : comment Google Design Sprint répondre à mes besoins ? En tant que designer talentueux, vous auriez déjà dû vous demander quelle valeur cela apporte réellement à l'équation et à quelle phase cela pourrait être le plus utile.
En tant que designer, je vais analyser et comparer ici les Google Design Sprint avec les nôtres Processus de conception du produit, fournissant un peu de contexte dans chaque cas.
Le design est l'âme fondamentale d'une création humaine qui finit par s'exprimer dans les couches extérieures successives du produit ou du service.
— Steve Jobs
Google Design Sprint est, comme le dit Google lui-même, « un processus permettant de répondre à des questions commerciales critiques par le biais de la conception, du prototypage et des tests » qui permet aux propriétaires de produits d'avoir « un raccourci pour apprendre sans créer et lancer un produit minimal viable ». En fin de compte, vous saurez si le concept de votre produit est bon, mais vous devrez tout de même faire beaucoup de conception avant de le mettre en œuvre.
Il s'agit d'un processus de cinq jours :
Jour 1. Déterminez le problème et choisissez un point important sur lequel vous concentrer ;
Jour 2. Esquissez des solutions concurrentes sur papier ;
Jour 3. Prenez des décisions difficiles et transformez vos idées en une hypothèse vérifiable ;
Jour 4. Élaborez un prototype haute fidélité ;
Jour 5. Testez-le avec de vrais humains vivants.
Le Processus de conception du produit est, en résumé, un processus qui vous guide à travers toutes les étapes de la création d'un produit. À la fin du processus, vous aurez tout ce dont vous avez besoin pour commencer à implémenter, ce qui explique le délai plus long requis.
Il suit un processus en quatre étapes, au cours duquel l'évaluation technique a lieu en même temps que les autres étapes :
Ensuite, la présentation de Sprint souligne clairement que l'évaluation de la viabilité de l'entreprise est son objectif principal, mais mentionne également qu'elle peut être appliquée à « créer la première version de nouvelles applications mobiles » ou « améliorer les produits auprès de millions d'utilisateurs ».
Bien que cela soit certainement possible, ce n'est pas un processus adéquat pour le faire, ce qui explique pourquoi Google ne présente pas la création de nouvelles applications mobiles comme son objectif principal.
Vous pouvez également parfaitement allumer un feu en frottant deux bâtons l'un contre l'autre, mais il y a très peu d'occasions où ce serait la meilleure façon de procéder.
C'est à ce stade que Google a certaines contraintes, en exigeant que nous n'ayons qu'un seul client cible et qu'un seul événement cible. En termes simples, cela signifie que si vous développez la première version d'une application mobile, celle-ci doit être très basique, car l'amélioration d'un produit existant se fait uniquement par l'ajout ou la modification d'une fonctionnalité.
Par exemple, vous pourriez modifier un élément à la fois, ce qui en ferait impossible de cibler deux personnages différents simultanément. Bien que n'avoir qu'un seul personnage cible puisse être le scénario idéal pour un designer, nous savons très bien que la plupart du temps, nous ne pouvons pas nous en tirer comme ça. Dans tous les cas, on ne peut pas les oublier, les personnages sont essentiels lors du développement d'un nouveau produit.
Si vous avez une application complexe, si vous souhaitez améliorer différentes fonctionnalités ou créer plusieurs nouvelles fonctionnalités, vous ne pourrez pas le faire en une seule fois. Pour ajouter du contenu supplémentaire, vous devrez effectuer plusieurs Design Sprints. C'est ce qui s'est passé avec l'étude de cas présentée dans le livre Sprint sur Slack, où il est indiqué que deux Sprints étaient nécessaires avant de commencer à le construire.
En revanche, le processus de conception du produit peut envisager plus d'un personnage, étant ainsi plus adapté aux produits qui exigent plusieurs rôles d'utilisateur. Par exemple, les applications de santé qui exigent des interfaces différentes pour les professionnels et les patients ou les applications pédagogiques utilisées à la fois par les enseignants et les étudiants.
Les contraintes liées au calendrier et à la personnalité et aux fonctionnalités ne sont que les premiers obstacles auxquels nous sommes confrontés lorsque nous choisissons Sprint pour développer une nouvelle application. Ce processus pose un problème plus important lorsqu'il est appliqué au développement de nouveaux produits, un problème qui ne peut être résolu en effectuant plusieurs Sprints ou en prolongeant sa durée.
Google Sprint vous présente que vous devriez le faire et dans quel ordre, mais cela ne vous donne aucune idée de comment pour passer d'une étape à l'autre, ni comment effectuer certaines des tâches intermédiaires.
Lorsque nous arrivons à la phase de création des visuels, Sprint mentionne que Créateurs (concepteurs ou ingénieurs) devraient créer les composants individuels : écrans, pages, pièces, etc., sous la direction de Le Sticher, qui devrait donner les guides de style à suivre. Cependant, il n'envisage pas la création de ces guides de style, le temps nécessaire pour les créer ou les tâches nécessaires pour définir le concept visuel sur lequel les guides de style sont basés. Ce n'est pas essentiel pour accéder à la viabilité du concept de produit (objectif principal de Sprint), mais c'est crucial si l'objectif est de le construire.
Quand la définition du concept visuel est négligée (pas fait ou terminé mais sans être basé sur des études de marché et d'utilisateurs) cela a de graves conséquences:
Il est peu probable que vous brûler une navette spatiale ou abattre un avion, mais une mauvaise expérience utilisateur peut très bien être catastrophique pour le succès de votre produit.
Lorsque vous créez du contenu, faites preuve d'empathie avant tout. Essayez de vivre la vie de votre public.
— Rand Fishkin, fondateur de Moz
Un cas moins flagrant, mais toujours similaire, se trouve au début du processus, dans le « Remixez et améliorez » jour (le deuxième). Ici, le processus vous indique « demandez à tous les membres de l'équipe de dresser une liste de produits ou de services à évaluer pour trouver des solutions inspirantes » puis présentez-les à l'équipe en notant les idées les plus utiles sur un tableau blanc.
Le problème est que ces références sont collectées en fonction des préférences et des expériences personnelles de l'équipe. Le processus n'envisage aucune saisie par l'utilisateur et n'est donc pas, en fait, une conception centrée sur l'utilisateur. Il est important de prendre en compte le fait qu'une fonctionnalité est uniquement « bien » d'un point de vue subjectif.
Une fonctionnalité utile pour quelqu'un peut être jetable ou même préjudiciable à d'autres. et il en va de même pour la convivialité et l'expérience utilisateur. Certaines personnes peuvent trouver une certaine façon d'afficher les informations de manière intuitive, tandis que d'autres peuvent la trouver confuse. Une personne peut trouver cela attrayant et une autre en est rebutée.
La façon de résoudre ce problème est de définir un profil utilisateur cible. et examinez les références que les personnes correspondant à ce profil ont et préfèrent. Bien que Sprint définisse un utilisateur cible dès le premier jour, il ne l'utilise pas vraiment pour orienter les décisions ultérieures concernant le produit. On ne le soulignera jamais assez, il faut design pour votre public cible, pas pour toi.
Il ne sert à rien (du point de vue de garantir le succès du produit) d'avoir un responsable de l'interface utilisateur qui ne soit ni l'un ni l'autre :
La seule raison possible est d'impliquer les clients dans le processus, de créer une meilleure relation avec eux et de faciliter les processus d'approbation, car ils se sentent les auteurs de la solution. Cependant, il n'y a aucun avantage en ce qui concerne la qualité du produit final.
En fait, cela peut même être nocif. Dans le contexte de Google Venture, Sprint peut fonctionner car tout le monde est immergé dans une culture du design, mais lorsque le responsable du produit est quelqu'un qui ne vient pas de l'environnement de conception du produit et qui ne connaît pas les profils d'utilisateurs potentiels, la tendance s'inverse.
Dans Processus de conception du produit, en revanche, même si vous n'avez pas eu l'occasion de contacter des utilisateurs potentiels pour connaître leurs références et préférences personnelles, l'équipe s'attache à se mettre à la place de l'utilisateur, en recherchant non pas ses propres références mais d'autres produits connus pour être utilisés et appréciés par les utilisateurs cibles.
Il faut comprendre l'utilisateur. Si tu ne peux pas, il ne pourra sûrement pas te comprendre non plus.
En résumé, c'est Processus de conception du produit mieux que Google Sprint? Cela dépend. Google Sprint est bien adapté aux premières étapes de la conceptualisation du produit, lorsque vous avez un nouveau concept de produit mais que vous ne l'avez pas clairement défini et que vous souhaitez accéder à sa viabilité.
C'est également crucial pour Google Sprint succès que toute l'équipe de conception connaît son public. Si tel est le cas, vous pouvez en tirer un avantage considérable en effectuant un sprint préliminaire.
Si vous avez accédé à la viabilité du produit avec Google Sprint et souhaitez passer à la mise en œuvre, vous pouvez profiter du Processus de conception du produit, qui n'impose aucune contrainte lors de la création d'applications plus complexes ou de la mise à niveau de fonctionnalités. Cependant, il est également possible de recommencer la conception à partir de zéro en utilisant la dernière version, qui couvre l'ensemble du processus de conception.
Le processus de conception de produits résout le problème de l'intégration de l'UX à la conception visuelle. Cela garantit aux concepteurs visuels qu'ils disposent de quelque chose de solide pour étayer leurs choix et leurs décisions, et pas simplement leurs préférences personnelles, ce qui facilite leur travail.
En ce qui concerne les chefs de produit, cela garantit que la conception UX ajoute une valeur concrète au produit et que ce n'est pas un effort inutile, en indiquant clairement comment chaque tâche UX se reflète sur l'interface graphique, ce qui aidera également l'équipe commerciale à traiter avec les clients potentiels, présentant ainsi l'intérêt de recruter des designers UX.
Enfin et surtout, cela signifie également que les développeurs n'auront pas à passer du temps à prendre des décisions de conception, souvent erronées, et que les interfaces proposées par les concepteurs sont faciles à mettre en œuvre.
À Imaginary Cloud nous avons une équipe d'experts en conception d'interface utilisateur et d'expérience utilisateur. Si vous pensez avoir besoin d'aide pour la conception, envoyez-nous un message ici!
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
Avec 10 ans d'expérience et une formation en sciences cognitives. Je suis passionné par le design inclusif et les technologies calmes.
People who read this post, also found these interesting:
