Une approche top-down du design produit en environnement Agile

Christophe Dujarric
3 juillet 2015

9 min read

Cet article a été traduit automatiquement depuis sa version originale.

Le design produit est un processus d’ingénierie.

Il ne s’agit pas uniquement de dessiner une belle interface utilisateur, il s’agit de construire une solution à un problème utilisateur.

C’est une succession d’étapes logiques de réflexion et de rédaction, que je recommande vivement de parcourir séquentiellement. Et la meilleure approche selon mon expérience est d’aller de haut en bas. Une fois de plus, il s’agit d’avoir la bonne discussion au bon moment.

L’approche va de :

l’analyse des exigences (problème utilisateur),
vers un design conceptuel,
puis un design fonctionnel,
pour aboutir à un design technique.

Le Pyramid Principle Logic in Writing & Thinking décrit en détail les bénéfices généraux de l’approche top-down. Cet article se concentrera sur son application dans le contexte du design produit, dans un environnement Agile.

Pourquoi adopter une approche top-down ?

J’ai observé une tendance récurrente dans les entreprises technologiques en start-up : se préoccuper d’abord de la technologie et de son implémentation technique, puis essayer de répondre aux exigences clients avec leur technologie.

Ne pas rater l’essentiel

Le problème avec ce processus : vous pourriez vous retrouver avec une technologie formidable, mais qui ne répond à aucun besoin. Et personne ne l’achètera, jusqu’à ce que vous fassiez des modifications. Dont certaines peuvent être très légères, et d’autres peuvent affecter l’architecture complète ou le modèle de données que vous avez choisi au départ. Pire, le canal de livraison peut être mauvais (peut-être que votre produit n’est finalement pas adapté au SaaS).

S’assurer que les choses simples restent simples

La situation la plus frustrante sera quand vous répondez effectivement à un besoin, mais qu’en résolvant d’abord par l’implémentation technique, vous pouvez vous retrouver à réinventer certains principes basiques d’expérience utilisateur ou même de vocabulaire. Et faire ça devient ensuite une galère pour l’onboarding de nouveaux utilisateurs, ou les activités marketing et commerciales, car vous devrez constamment expliquer des fonctionnalités qui auraient autrement été explicites.

Soyez lean !

Enfin et surtout, cette approche est la meilleure voie vers un développement produit lean. En obtenant une vue d’ensemble de vos exigences produit en fonction de votre marché, de vos utilisateurs et clients, il sera naturel de prioriser votre roadmap, et de décider éventuellement de reporter telle ou telle fonctionnalité non critique pour livrer une solution. C’est ce qu’on appelle construire votre Minimum Viable Product.

Illustrer l’approche avec la SADT

Structured Analysis and Design Technique.

J’aime illustrer les choses avec cette technique. Probablement ce qui reste de mes études d’ingénieur.

À chaque étape du design, vous devriez penser à une boîte noire, avec seulement :

Une entrée
Une sortie
Un contrôle
Des actions

Voyons un cas d’usage simple.

Vous êtes une entreprise technologique spécialisée dans la sécurité des bâtiments. Votre client a engagé un unique gardien pour contrôler toutes les entrées du site. Ce gardien peut aussi avoir d’autres tâches à effectuer, ce qui rend impossible pour lui de surveiller toutes les portes ou la vidéosurveillance. Il doit cependant vérifier l’identité de chaque visiteur avant qu’il entre sur le site.

Cas d’usage

Concept : détecteur de mouvement

Vous pouvez commencer par proposer un dispositif de détection de mouvement et d’alerte.

Attendez, quoi ? C’est déjà un choix que vous avez fait ! Vous êtes maintenant au stade du “Concept”. Et vous avez en quelque sorte fermé des portes. Qui a dit que c’était la seule solution au problème de cet utilisateur ? Étant une entreprise technologique hardware, vous valoriserez votre compétence distinctive. C’est donc OK. Mais il aurait peut-être valu la peine de vérifier d’autres options.

C’est tout ce que vous avez besoin de décrire pour l’instant !

Fonctionnalités

Une façon simple de concrétiser cela serait d’avoir les éléments suivants :

Implémentation

Pour la partie “émission” spécifique, vous pourriez par exemple utiliser un bon vieux circuit intégré NE555 comme générateur d’impulsions.

OK, venez-en au fait !

Quel est mon point ? À chaque étape, j’ai fait des choix (bons ou mauvais). Ils ont directement ouvert des portes, mais en ont fermé beaucoup d’autres.

Si j’avais commencé directement au niveau de l’implémentation, je n’aurais jamais eu la chance de voir plus d’options, qui auraient pu être plus appropriées vis-à-vis de mes objectifs business tout autant que des besoins de l’utilisateur.

La technologie doit toujours être un levier, pas une solution en elle-même !

Comment Scrum soutient cette approche

Position dans le backlog et niveau de détail des User Stories

Comme indiqué sur le schéma ci-dessous, la meilleure façon de maintenir votre backlog est de jouer avec le niveau de détail dans lequel une user story est écrite, et sa position dans le backlog.

Quand une user story exprime simplement un problème utilisateur, elle devrait être quelque part en bas du backlog. Et probablement que son estimation en points de complexité sera haute (vous n’avez aucune idée de ce que vous allez faire).

Quand une user story est en haut du backlog, le mieux est de savoir exactement comment la fonctionnalité va fonctionner, d’avoir les maquettes prêtes, et potentiellement les lignes directrices d’implémentation prêtes.

Où écrire quoi dans Jira

Si vous utilisez Jira, je vous recommande vivement ceci :

Décrire le concept dans un Epic
Décrire les fonctionnalités de cet Epic dans des User Stories (l’objectif est d’avoir des stories inférieures à 8 pts, rappelons-le !)
Décrire l’implémentation de chaque story dans des sous-tâches

Lors d’un sprint, quand toutes les sous-tâches sont terminées, y compris une sous-tâche “test et validation”, vous pouvez considérer la story comme terminée.

Regrouper correctement les stories en epics facilitera la navigation dans le backlog et la priorisation des sprints, mais permettra aussi de faire les bons compromis sur les MVPs pour chaque Epic, sans jamais oublier de fonctionnalité. (Les issues non liées aux Epics ont tendance à se perdre au fond du backlog).

L’utilisation des Epics facilitera la création d’une roadmap visuelle. L’idéal est de configurer votre type d’issue “Epic” dans Jira pour avoir une date de début et une date de fin estimées. L’interface entre Jira et Confluence vous permettra ensuite d’afficher votre Roadmap via la fonctionnalité Calendriers. Visuellement attrayant, facile d’explorer les Epics vers les Stories, de Confluence à Jira. Idéal pour les conversations avec votre manager ou vos parties prenantes business.

Comment écrire un bon Epic

Compte tenu de ce qui précède, vous comprenez à quel point il est crucial de décrire correctement votre Epic.

Je pourrais commencer à parler de MRD ou de PRD, mais ce n’est pas vraiment “agile”. Pour moi, vous pouvez vous en tenir à 3 choses :

Le problème utilisateur décrit en quelques phrases (idéalement une)
Votre solution conceptuelle, en quelques phrases
Un Product Opportunity Assessment, tel que décrit par Marty Cagan, il y a déjà quelques années.

Plus la description est courte, plus vous avez de chances que vos développeurs la lisent entièrement.

Ne jamais mettre vos maquettes là ! Elles appartiennent aux stories ! (Sinon ce sera une autre façon d’écrire un livre dans la description de votre Epic)

Pour aller plus loin

Problème utilisateur / Objectif utilisateur

Je me réfère souvent à ce que j’appelle le problème utilisateur. Regardons un peu plus ce que j’entends par là.

Les user stories ne sont pas l’ensemble des exigences. Les développeurs Agile veulent des user stories ; les product managers veulent ramener du marché des histoires sur les utilisateurs. Ce dont nous avons vraiment besoin, cependant, c’est de comprendre les objectifs des utilisateurs.

Écrit Edward Brown. Il propose un exercice très intéressant dans son blog pour mieux comprendre comment définir cet objectif utilisateur.

J’ai l’habitude de mentionner un Problème Utilisateur (au lieu d’objectif), par opposition à la solution que j’essaie de construire pour l’utilisateur.

Ce qui est aussi très important, c’est que le Problème Utilisateur devrait englober le contexte du marché. Et là vous faites le lien avec le Persona Utilisateur, qui devrait être mentionné dans le titre de chacune de vos user stories… 😉

S.M.A.R.T.

Je l’ai déjà rapidement mentionné dans un article précédent. C’est une autre façon de s’assurer qu’on fixe des objectifs clairs. Je préfère le Product Opportunity Assessment de Marty, mais c’est quand même une bonne vieille recette.

Écrire un Epic, c’est aussi comme fixer un objectif. Le rendre S.M.A.R.T. implique de s’assurer qu’il est :

Spécifique
Mesurable
Assignable
Réaliste
Temporellement défini

La partie cool, c’est que vous couvrez probablement déjà certains de ces paramètres si vous travaillez en Agile, notamment via les définitions de “Prêt” et “Terminé”.

Points d’attention

Voici des problèmes que j’ai rencontrés lors du design produit, en court-circuitant l’approche top-down.

Ce n’est pas le problème utilisateur que vous cherchez

Interviewer des utilisateurs et des clients peut être un exercice délicat. Souvent, les utilisateurs auront tendance à décrire ce qu’ils veulent que le produit fasse, plutôt que le problème qu’ils aimeraient qu’il résolve. Cela fait sauter directement le processus à l’étape 3, voire 4. Et voilà que vous perdez la cohérence de votre produit, et la “dette fonctionnelle”.

Assurez-vous d’être aux commandes lors de l’entretien, et de comprendre exactement ce dont vos utilisateurs ont besoin !

Le Jenga de votre produit

Ce n’est pas parce que vous pouvez implémenter une fonctionnalité que vous devriez le faire.

Certaines nouvelles implémentations peuvent avoir un impact direct sur l’ensemble de votre produit, voire sur votre processus de vente. Et là où vous pensiez avoir une excellente idée, vous brouilllez en réalité toute la histoire et perdez des clients.

Un exercice intéressant cependant, même dans le concept “Jenga”, est de se demander à chaque fois que vous ajoutez une nouvelle fonctionnalité si vous pouvez en supprimer une autre à la place.

Fonctionnalité copier-coller

Cela pourrait être une très mauvaise idée ! Du moins si vous ne passez pas réellement par tout le processus de design dont nous avons parlé.

Essayer de réutiliser un travail déjà réalisé est très bien en termes de réduction du time-to-market. Mais si vous pensez : “Oh, cette fonctionnalité est super, je vais juste la réutiliser dans cet autre produit qui semble avoir des points communs avec le premier…”… Eh bien, vous êtes sur le point de rater complètement le problème utilisateur !

En effet, tant que vous n’avez pas compris et défini l’essence du problème utilisateur, comment pouvez-vous savoir que cette fonctionnalité spécifique est réellement une solution pour lui ? Il n’y a pas de place pour l’approximation !

Bien sûr, vous devrez quand même faire attention à ne pas réinventer la roue à chaque fois, donc le travail passé est définitivement une expérience précieuse, et devrait être pris en compte pour améliorer la cohérence entre vos produits.

Références

Image de une par espinozr

Tags :

product design Agile SaaS engineering solution design