Le chef de produit est souvent décrit comme le « pont entre le business, le design et la technologie”. Le pont « entre le design et la technologie » est particulièrement critique lorsqu’il s’agit d’expédier un produit de qualité: sans bug, parfait pour les pixels et qui prend en compte tous les scénarios et cas de bord possibles. Pour vous assurer que bridge fonctionne bien, voici plusieurs façons dont il est géré par l’équipe de conception:

• Le concepteur expédie un prototype complet, qui montre tous les flux du produit. Malheureusement, cela prendra souvent beaucoup de temps et manquera encore quelques cas de bord.
• Le concepteur n’expédiera qu’un prototype qui montre les principaux flux de la fonctionnalité, et reste disponible pour les questions de l’équipe de développement. Malheureusement, ces allers-retours sont très inefficaces (en particulier dans une configuration à distance) et font perdre beaucoup de temps à l’équipe de conception et de développement.
• Le concepteur, en plus du prototype complet, écrit un document de spécifications approprié qui répertorie tous les scénarios possibles et les cas périphériques. Le problème est que c’est souvent une perte de temps, car (1) le temps précieux des concepteurs sera mieux dépensé en concevant d’autres fonctionnalités, pas en écrivant un document de spécification, et (2) ils n’ont pas toujours la même vue à 360 ° du produit que les chefs de produit, ce qui les amènera à négliger certains scénarios et cas de bord.

C’est pourquoi les équipes de produits matures confient généralement la rédaction des spécifications de leurs produits aux chefs de produits.

Mais comment écrire les spécifications des produits? J’ai rédigé des spécifications de produits au cours des 5 dernières années et j’ai trouvé un format très apprécié par les équipes logicielles avec lesquelles je travaille. Dans cet article, je partage plus sur ma méthodologie et les outils que j’utilise pour rédiger les spécifications des produits. Je décris également certaines limitations auxquelles je suis confronté avec les outils que j’utilise et certaines idées d’amélioration que j’ai en tête.

Voici les 5 principaux sujets que j’aborde dans une spécification de produit:

1. Contexte et objectifs
2. Carte d’architecture
3. Epics et User stories
4. Critères d’acceptation
5. Conception, contenu et traductions

Contexte et objectifs

Même si les spécifications du produit sont principalement destinées aux équipes logicielles, elles aiment toujours savoir pourquoi elles travaillent sur ce sur quoi elles travaillent. J’ai fini par comprendre que l’un des principaux moteurs de motivation des ingénieurs logiciels est l’impact. La plupart d’entre eux rêvent de travailler sur des fonctionnalités utilisées par des millions d’utilisateurs. Ils sont ravis d’apprendre que la nouvelle expérience utilisateur qu’ils ont mise en œuvre a augmenté la rétention de 15%, par exemple. Il est donc important de donner un contexte sur la fonctionnalité qu’ils vont implémenter :

• De quoi parlons-nous ? Quelle partie du produit? N’hésitez pas à ajouter tout historique de la fonctionnalité utile pour comprendre la situation actuelle.
• Quel est le problème actuel? Remarque: Il peut y avoir plusieurs problèmes à résoudre.
• Y a-t-il des commentaires / verbatims qualitatifs des utilisateurs à citer?
• Y a-t-il des données (par exemple des graphiques) à afficher? Dans cette section, n’hésitez pas à inclure des tableaux ou des graphiques qui rendront les données plus compréhensibles.
• Quelle est la solution choisie ? (décrivez-le simplement, en quelques phrases)
• Une autre solution a-t-elle été envisagée? Si oui, pourquoi a-t-il été mis de côté?
• Une autre solution a-t-elle déjà été implémentée ? Comment a-t-il fonctionné?
• Quels sont les objectifs ? Y a-t-il des indicateurs clés de performance que nous essayons d’avoir un impact? Cela aidera particulièrement l’équipe logicielle à comprendre si elle doit implémenter de nouveaux trackers / tags / événements pour collecter correctement les données. J’ai vu des équipes se sentir tellement motivées par le projet qu’elles ont pris l’initiative de configurer des tableaux de bord pour suivre les métriques en temps réel, sans que moi ni personne d’autre ne le demande.

Carte d’architecture

Avant d’entrer trop dans les détails de la fonctionnalité, il est important de donner un aperçu de haut niveau de ce qui change et de ce qui reste le même dans votre produit. Et même si vous travaillez sur un produit entièrement nouveau, une carte d’architecture sera toujours extrêmement pertinente pour comprendre comment le produit est structuré.

« Carte d’architecture » est la façon dont j’appelle une représentation schématique de haut niveau des fonctionnalités du produit (flux, écrans et contenu) et de la façon dont elles sont liées ensemble. Certaines personnes l’appellent « Architecture d’information », ”Carte de flux », ”cartographie UX », etc.

Il n’y a pas de méthodologie officielle pour dessiner une carte d’architecture. Sur une application mobile, j’essaie généralement de différencier les flux, les écrans et les « parties d’un écran” (ou « contenu en page”), en utilisant une forme différente pour chacun d’entre eux, comme détaillé dans la légende ci-dessus.

Il peut également être utile de jouer sur le code couleur. Dans l’exemple ci-dessus, j’ai utilisé 3 couleurs et aussi une ligne en pointillés par rapport à la ligne en pointillés pour expliquer comment l’architecture d’information actuelle serait mise à jour avec la refonte de l’UX de l’application sur laquelle nous travaillions. (vert: restera tel quel, orange: sera mis à jour, rouge: sera supprimé; solide: restera au même endroit, pointillé: sera déplacé ailleurs). De cette façon, les ingénieurs avaient une vue d’ensemble claire de la partie de l’application susceptible d’être modifiée.

Une autre astuce pour construire une carte d’architecture compréhensible est de distinguer clairement les différentes parties de la navigation, comme cela est fait ci-dessous avec des zones distinctes pour chacune d’elles.

Avoir une carte d’architecture sera extrêmement utile pour les spécifications de votre produit; il vous permettra de mettre en évidence la partie du produit dont vous parlez dans chacune de vos histoires d’utilisateurs.

Quel outil devez-vous utiliser pour dessiner une carte d’architecture ? Il y en a des tonnes disponibles là-bas, mon préféré est fantaisiste (car il est visuellement agréable et très simple, pas encombré de tant de fonctionnalités), mais j’ai aussi utilisé Draw.io dans le passé — ce qui est intéressant car il est intégré à Google Drive, donc si vous travaillez avec Google Slides et Google Docs, cela le rend agréable à utiliser. Il est également intégré à JIRA et Confluence.

Si vous souhaitez en savoir plus sur les cartes d’architecture (à faire et à ne pas faire, quels outils utiliser, quelques exemples, etc.), Toptal a trouvé une excellente lecture: Le Guide Complet de l’Architecture de l’Information.

Epics et User stories

Décomposer et expliquer toutes les parties de votre produit peut très rapidement devenir assez chaotique. En écrivant des spécifications de produits au cours des 5 dernières années, la meilleure façon que j’ai trouvée de garder les spécifications organisées et compréhensibles est de les décomposer en fonction des « user stories”.

Qu’est-ce qu’une user story ? Selon la modélisation Agile, une user story est « une définition de très haut niveau d’une exigence, contenant juste assez d’informations pour que les développeurs puissent produire une estimation raisonnable de l’effort pour la mettre en œuvre.”

L’idée des user stories est de donner la priorité aux utilisateurs et d’éviter d’utiliser exclusivement un vocabulaire technique &obscur lors de la discussion des fonctionnalités. Comme le dit Atlassian :  » Après avoir lu une user story, l’équipe sait pourquoi elle construit ce qu’elle construit et quelle valeur cela crée. »

Ils visent à construire un meilleur produit où l’utilisateur est au centre des débats, contrairement au bon vieux développement de produits en cascade.

Voici comment une histoire d’utilisateur doit être formulée:

En tant que <type d’utilisateur >, je veux < un objectif > de sorte que < une raison >.

Par exemple, voici comment nous pourrions formuler des histoires d’utilisateurs pour la sous-partie suivante de la carte d’architecture que j’ai dessinée pour l’un de mes clients :

• User Story #1: En tant qu’employé de la section profil, je souhaite modifier mon profil afin de pouvoir mettre à jour ma photo, mon prénom et mon nom de famille.
• Histoire de l’utilisateur #2: En tant qu’employé de la section profil, je souhaite accéder aux paramètres afin de pouvoir mettre à jour mon mot de passe et mettre à jour les préférences de notification.
• User Story #3: En tant qu’employé de la section profil, je souhaite accéder au chat afin de pouvoir donner des commentaires aux développeurs de l’application

C’est au chef de produit de décider du niveau de détails qu’il souhaite couvrir dans l’user story. Si nous le voulions, nous pourrions également aller plus loin dans la User Story #2, par exemple :

• User Story #2.a: En tant qu’employé dans les paramètres, je souhaite accéder à la section « modifier le mot de passe” afin de pouvoir mettre à jour mon mot de passe
• User Story #2.b: En tant qu’employé dans les paramètres, je souhaite accéder aux préférences de notifications afin de pouvoir mettre à jour la fréquence à laquelle je reçois chaque type de notifications

Mais comme vous le voyez, c’est quelque peu évident et redondant. J’ai personnellement choisi de couvrir ces scenarii dans les ” critères d’acceptation » (voir section suivante) des histoires en question.

Pour organiser les user stories, nous utilisons souvent des  » épopées « . En termes agiles, les ”épopées » sont de grandes quantités de travail qui peuvent être décomposées en histoires d’utilisateurs plus petites. Personnellement, j’utilise des épopées pour regrouper des histoires qui font partie du même thème ou de la même zone du produit. Par exemple, j’ai choisi de regrouper les histoires ci-dessus dans le cadre de l’épopée « Profil”. Certaines personnes choisissent de formuler des épopées de la même manière que les histoires d’utilisateurs, avec une structure plus simple (par ex. ” En tant qu’utilisateur, je souhaite accéder à mon profil »)

Critères d’acceptation

Pour être sûr d’ajouter suffisamment de détails à une user story, nous utilisons des ” critères d’acceptation » (parfois aussi appelés ” conditions de satisfaction »).

Selon LeadingAgile.com , les  » critères d’acceptation  » sont  » les conditions qu’un produit logiciel doit remplir pour être accepté par un utilisateur, un client ou, dans le cas d’une fonctionnalité au niveau du système, le système consommateur. »

Dans les critères d’acceptation, vous devez lister toutes les spécificités fonctionnelles qui ne sont pas clairement énoncées par l’histoire de l’utilisateur. Exemple:

User Story

En tant qu’employé de la section profil, je souhaite modifier mon profil afin de pouvoir mettre à jour ma photo, mon prénom et mon nom de famille.

Critères d’acceptation

• Étant donné que je suis sur l’écran modifier le profil Lorsque je clique sur l’icône modifier le prénom, il devrait passer en mode édition, se concentrer sur l’entrée et ouvrir le clavier (idem pour le nom de famille)
• Étant donné que je suis sur l’écran modifier le profil Lorsque je clique sur l’icône modifier la photo, il devrait me demander de choisir entre appareil photo et bibliothèque
• Étant donné que je modifie mon prénom Lorsque je clique sur « enregistrer”, il devrait me rediriger vers le mode de lecture et Je devrais voir une notification de succès

etcetc

Considérez les critères d’acceptation comme un liste de contrôle qui devra être remplie pour que le produit soit expédié. Le format Donné / Quand / Alors utilisé ci-dessus est un bon moyen de vous aider à formuler vos critères d’acceptation, mais dans certains cas, il peut être difficile à utiliser.

Conception, contenu et traductions

Avoir des conceptions à jour dans vos spécifications de produit

Jusqu’à présent, je n’ai pas mentionné quel outil j’utilise pour écrire des spécifications. Dans le passé, j’ai basculé entre Google Docs, Google Slides et Notion. J’ai vraiment aimé utiliser Notion pour toutes les intégrations sympas qu’elle offre (en particulier celles avec InVision et Figma). Mais je suis maintenant complètement passé à Google Docs: je préfère avoir plus de liberté dans la façon dont je formate mes spécifications de produit. Il est également plus pratique d’utiliser les produits Google lorsque vous travaillez avec des partenaires ou des clients externes.

Pour s’assurer que l’identité visuelle de votre produit est correctement concrétisée par l’équipe de développement, il est important de lui donner accès aux écrans les plus à jour expédiés par votre(vos) concepteur(s). Mais comme il n’y a pas de réelle intégration entre Google Docs et des outils de conception comme Figma, InVision ou Zeplin, j’avais l’habitude d’exporter des écrans et de les copier / coller dans les spécifications de mes produits.

Cela deviendrait très vite un problème: les concepteurs itèrent quotidiennement sur leurs écrans, et même lorsque tout a été convenu sur un écran, cela peut changer quelques semaines plus tard en raison de la mise à jour d’un composant spécifique dans la bibliothèque de conception. Cela rendrait mes spécifications obsolètes la plupart du temps.

C’est pourquoi aujourd’hui je n’utilise que le nom des écrans. Par exemple, si une histoire d’utilisateur sur l’édition de profil concerne 2 écrans conçus sur Figma, je n’écrirai que « Nom d’écran Figma: edit-profile-1 et edit-profile-2″”

Bien sûr, ce n’est pas idéal et contraint les développeurs ou toute autre personne lisant mes spécifications à basculer entre plusieurs outils.

Mais cela montre qu’il y a aujourd’hui quelque chose d’inefficace dans la façon dont nous écrivons les spécifications des produits. L’utilisation de plusieurs produits pose des questions d’intégration et de synchronisation. Comment s’assurer que toutes les informations nécessaires à la construction d’un produit sont visibles en un seul endroit, sans être obsolètes ? (En fait, cela ne s’applique pas seulement aux conceptions, mais aussi aux cartes d’architecture et au contenu).

→Si vous rencontrez également ce problème et que vous avez trouvé une solution, je serais intéressé de recevoir vos commentaires!

Donner un accès facile au contenu et aux traductions pour éviter les fautes de frappe

Lorsque vous concevez des écrans avec une grande quantité de contenu, il est agréable de donner aux développeurs la possibilité de le copier / coller facilement au lieu de devoir le re-taper eux-mêmes. Sinon, vous pourriez vous retrouver avec (1) de nombreuses fautes de frappe et (2) des développeurs énervés. Il existe plusieurs façons de leur donner accès au contenu:

• En leur donnant accès aux fichiers sources du travail de conception sur Sketch, Figma ou Zeplin par exemple.
• En copiant / collant le contenu directement dans la spécification (cela peut le rendre un peu désordonné).

Si votre produit existe en plusieurs langues, donnez également accès à chaque traduction. Par exemple, vous pouvez utiliser un tableau pour afficher la traduction de votre contenu original dans chaque langue. Le prochain niveau de gestion de la traduction consiste à utiliser un outil de localisation (comme Phrase) et à n’ajouter que les « clés de traduction” dans les spécifications de votre produit. Mais encore une fois, cela implique un va-et-vient supplémentaire entre les spécifications de votre produit et un autre outil.