Meilleure documentation et communication d'équipe avec les documents de conception de produits

Le processus typique pour travailler en tant que concepteur de produit dans une entreprise ou une startup peut vous être familier : un nouveau produit est en cours de développement pour lequel fournir une solution de conception. Ensuite, vous travaillez sur des propositions de conception et vous les présentez devant 1 à 3 personnes pour recueillir des commentaires.

Parfois, ce processus fonctionne très bien, mais d'autres fois, ce n'est pas le cas. Par exemple, certaines personnes sont occupées à terminer leurs propres tâches et ne passent pas assez de temps pour fournir des commentaires clairs et concis sur votre proposition de conception.

Il peut également arriver que même si votre processus est bon, vous souhaitiez toujours formaliser le processus en écrivant des décisions, en gardant une trace des itérations et du processus de conception en général, en particulier à l'heure actuelle où nous nous retrouvons à travailler à distance en raison de COVID19.

Documenter le processus présente de nombreux avantages. Par exemple, cela rend votre travail plus visible, crée des opportunités d'obtenir des commentaires de beaucoup plus de personnes, améliore la communication globale et fournit une image claire de la façon dont une fonctionnalité a été conçue avec tout le contexte et les considérations qui l'entourent.

La chute du concepteur de héros

Vers 2018, je travaillais en tant que Product Designer à distance depuis Madrid dans une entreprise opérant en Amérique latine, impliquant dans ce processus d'autres équipes du Mexique et de Sao Paulo, au Brésil.

Avant de commencer à travailler dans cette entreprise, j'ai eu beaucoup d'expériences différentes dans ma carrière en travaillant dans des environnements de petite et grande taille de nombreux secteurs différents comme les médias d'information, les studios de design, un réseau social, un système d'exploitation mobile, fondé une startup d'épicerie en ligne , et a même fait quelques concerts indépendants avec d'autres petites startups.

Au cours de ces années, j'ai suivi la même approche, vous obtenez des personnes assises dans la même pièce, vous présentez votre solution, vous fournissez des écrans, des flux, vous obtenez des commentaires et vous la présentez à nouveau. Après quelques itérations, votre travail sera prêt à atteindre la phase de développement.

Cependant, cette même approche a cessé de fonctionner. Peu de temps après avoir rejoint l'équipe, j'ai réalisé qu'il ne suffisait pas de présenter mes créations lors d'un appel vidéo. Je créais beaucoup de propositions, mais je n'arrivais pas à obtenir l'approbation finale de mes parties prenantes et de mes coéquipiers. J'étais confuse et je me demandais : que se passait-il ? N'étais-je pas en train de concevoir la meilleure solution possible ? N'étais-je pas en train de fournir un travail de bonne qualité ? Chacune de ces questions me faisait perdre confiance en moi. Le problème était que je devais adapter mon processus à cet environnement.

Dès que j'ai réalisé que mon processus ne fonctionnait pas, j'ai commencé à lire beaucoup d'articles sur comment travailler en tant que designer à distance, l'effet mouette (quand quelqu'un entre dans votre travail, le critique durement puis s'envole), comment d'autres entreprises abordaient la collaboration à distance et comment elles ont formalisé leur processus en l'écrivant. Après avoir lu tout ce matériel, je me suis demandé comment les développeurs faisaient face à ce même problème ? Comment collaborent-ils sur des environnements distants de manière quasi asynchrone ? Comment parviennent-ils à des accords définitifs ? J'ai découvert qu'en fait, la communauté des développeurs a déjà un processus qui fonctionne plutôt bien pour eux : cela s'appelle les pull requests.

Les demandes d'extraction vous permettent d'introduire des modifications dans une base de code plus large en les documentant et en validant vos décisions avec les commentaires d'autres personnes. De cette façon, les changements que vous introduisez se mélangent parfaitement avec toutes les normes et connexions que le code a déjà en place. C'est exactement ce que je devais réaliser, mais bien sûr dans une approche design-mode. Permettez-moi de vous présenter le Product Design Doc.

Le document de conception de produit

Un document de conception de produit (PDD) est un document qui convertit les problèmes que vous souhaitez résoudre, le contexte et la solution finale en une itération ou une approche par étapes.

Cela signifie que vous pouvez documenter l'ensemble de votre processus de conception dans un seul document qui peut être partagé avec n'importe qui dans votre entreprise et qui servira de base de connaissances pour les décisions que vous prendrez concernant les produits. Ça a l'air cool, hein ? Creusons dans les détails.

Concepts généraux

Un PDD peut être décrit en 4 concepts majeurs : Métadonnées, Contexte, Étapes et Commentaires .

• Les métadonnées ne sont que des informations utiles sur le document telles que le titre, la date, le statut, etc.

  

• Le contexte est ce que les autres doivent lire, pour comprendre les propositions de conception que vous faites, pensez-y comme la description, le problème, le résumé ou les objectifs de ce que vous devez réaliser.

• Les étapes sont les différentes itérations de votre conception, commençant généralement à se concentrer sur la solution plus large et à chaque étape se concentrant sur des détails plus spécifiques. Chaque étape est basée sur la précédente et répond aux commentaires reçus. Il s'agit d'une manière structurée d'atteindre un point final où les problèmes résolus ne peuvent plus réapparaître.

• Les commentaires font référence à toutes les opinions, commentaires, demandes et recommandations que vous recueillez auprès d'autres personnes. Vous pouvez recueillir les commentaires de vos parties prenantes ou des membres de votre équipe.

Avec ces quatre concepts, vous pouvez créer différentes variantes de PDD pour répondre à vos besoins, chaque entreprise/projet est différent et ce qui a fonctionné pour moi ne doit pas nécessairement fonctionner de la même manière pour vous. Mais si vous couvrez ces 4 concepts principaux dans votre PDD, cela fonctionnera probablement dans presque toutes les situations.

Exemple de structure

Après avoir compris les principaux concepts, je partagerai avec vous la structure que j'ai utilisée pendant mon séjour dans cette entreprise. Il comporte les rubriques suivantes :

• Le titre doit être concis, clair et facile à distinguer des autres titres PDD que vous possédez déjà.
• Le statut indique à quelle étape se trouve votre document en ce moment :
• Brouillon
  Toujours en train de définir le contexte. Pas prêt pour les commentaires.
• S30, S60, S90
  Les différentes étapes (30%, 60%, 90%) de votre solution (plus de détails sur les étapes plus loin).
• Compléter
  Tous les commentaires ont été traités et il ne manque aucun point. Le PDD est terminé.
• Le résumé est la description du problème pour lequel vous devez concevoir, généralement lié à d'autres lectures connexes utiles que vous pourriez avoir.
• Les objectifs sont les points clés sur lesquels votre solution doit se concentrer, il s'agit d'une liste de contrôle que vous réviserez constamment pour vous assurer que vous êtes sur la bonne voie.
• S30 (ou Stage 30% ) est la première proposition que vous faites sur la base du résumé et des objectifs, en vous concentrant sur la solution plus large plutôt que sur les détails, peut-être en fournissant un wireframe basse fidélité ou une technique similaire. C'est l'étape où la solution proposée pourrait adopter une approche totalement différente et des retours importants sont attendus.
• S60 (ou Stage 60% ) est votre solution à 60% d'exhaustivité et applique les retours de S30. Il contient moins de détails que le S90, mais indique clairement l'intention de votre solution. Vous fournissez un wireframe haute fidélité avec plus de cas impliqués et quelques définitions de flux. Vous pourriez recevoir une sorte de rétroaction axée principalement sur les cas manqués et les petits scénarios inattendus.
• S90 (ou Stage 90% ) est l'étape qui a la solution à 90% d'exhaustivité et applique les retours de S60. Cette étape se concentre sur les détails les plus fins de votre conception, y compris tous les différents scénarios, les cas d'angle, la conception visuelle et même les prototypes. On s'attend à ce qu'il y ait une sorte de rétroaction mineure.

Vous vous demandez peut-être si je dois suivre le même ordre et la même convention de dénomination des étapes ? Eh bien, non. Vous pouvez renommer l'étape S30, S60 et S90 en juste : Exploration, Proposition, Solution.

Vous pouvez également modifier l'ordre afin que le travail le plus raffiné (S90, Solution) soit placé en haut du document et que le flux de lecture passe de l'étape finale à la première (S30, Exploration).

Modèles

Commencez rapidement avec l'un des modèles fournis pour les plates-formes d'écriture les plus courantes. N'oubliez pas : Les conventions de nommage des sections sont totalement personnalisables. Si vous n'aimez pas Abstract , utilisez simplement Brief , About ou tout ce qui correspond à vos besoins. Le concept principal que vous devrez conserver consiste à créer différentes itérations pour vous concentrer sur chaque étape, vous pouvez simplement renommer S30 par Exploration, S60 par Proposition et S90 par Solution.

• Papier
• Notion
• Google Docs
• Exemple concret

Principaux avantages de l'utilisation de PDD

1. Chaque décision est documentée.
   Cela signifie que même lorsque vous quittez votre entreprise/projet (et cela arrivera tôt ou tard), toutes les connaissances générées resteront dans l'entreprise pour toujours, afin que d'autres personnes puissent la regarder et itérer à partir de là où vous êtes parti.

2. Améliore la communication.
   Faire en sorte que différentes personnes de votre équipe sur le PDD fournissent des commentaires aide tout le monde à rester sur la même longueur d'onde et à être au courant des décisions prises.

3. Limite les changements sans fin des parties prenantes.
   Chaque étape se concentre sur un angle différent du problème, allant de solutions plus larges à des solutions étroites. Cela permet aux gens de se concentrer sur un seul problème à la fois, ce qui les aide dans les étapes finales.

4. Le produit est construit en collaboration.
   Au lieu que les parties prenantes définissent des solutions spécifiques, nous laissons les équipes d'ingénierie, de conception et autres s'engager avec la solution en les intégrant à celle-ci.

Remarques finales

Pour clore l'histoire de cette entreprise distante, j'ai pu y travailler pendant quelques mois de plus et j'ai pu mettre en œuvre les Product Design Docs au moins sur 5 projets différents. Ma frustration a été beaucoup réduite et j'ai pu parvenir à un consensus sur mes propositions de conception afin que le produit continue d'évoluer. Depuis lors, l'entreprise a beaucoup grandi et une partie du travail que j'ai effectué pendant mon temps est toujours utilisée.

PS : J'ai commencé à écrire cet article en 2019, puis en 2021 j'ai vu qu'Abstract était en train de créer un produit pour documenter le processus de conception, j'ai donc décidé de me remettre sur les rails et de le terminer. On dirait que c'est toujours un sujet d'actualité.

Bibliographie

• Comment exécuter des exercices de conception sur une équipe à distance par Hannah Hearth
• Évitez l'effet mouette : le cadre 30/60/90 pour les commentaires par Lauren Moon
• Comment concevoir un document de conception ? par John Saito
• La puissance du design doc par Brendan Fagan
• Présentation des cahiers de Matt Colyer