Une meilleure documentation et une meilleure communication d'équipe grâce aux documents sur la conception de produits

À propos de l'auteur

Ismael a travaillé au cours des 13 dernières années au sein d'équipes de conception dans des petites et grandes entreprises de différents secteurs comme les médias d'information, le design…
En savoir plus sur
Ismael
↬

Le processus typique de travail en tant que concepteur de produit dans une entreprise ou une startup pourrait vous être familier: un nouveau produit est en cours de développement pour lequel fournir une solution de conception. Ensuite, vous travaillez sur certaines propositions de conception et vous les présentez à 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 à prêter attention à la fin de 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 vouliez quand même formaliser le processus en écrivant les décisions, en gardant une trace des itérations, et le processus de conception en général, en particulier dans les temps actuels où nous nous trouvons à travailler à distance en raison de COVID19.

Documenter le processus a de nombreux avantages. Par exemple, il 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.

The Fall Of Le Hero Designer

Vers 2018, je travaillais en tant que Product Designer à distance de Madrid dans une entreprise qui opère en Amérique latine, impliquant dans ce processus d'autres équipes du Mexique et de São Paulo, Brésil. [19659011] Emplacements cartographiques distants « />

Avant de commencer à travailler dans cette entreprise, j'ai eu de nombreuses expériences différentes au cours de ma carrière en travaillant dans des environnements de petite et grande taille dans de nombreux secteurs différents comme des médias d'information, des studios de design, un réseau social, un système d'exploitation mobile, fondé une start-up d'e-épicerie et même fait des concerts en freelance avec d'autres petites startups.

Pendant ces années, j'avais suivi la même approche, vous obtenez des gens sitti ng dans la même pièce, présentez votre solution, fournissez des écrans, des flux, obtenez des commentaires et présentez-la à 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é que le simple fait de présenter mes créations lors d'un appel vidéo ne suffisait pas. J'étais en train de créer beaucoup de propositions, mais je n'ai pas pu obtenir l'approbation finale de mes parties prenantes et de mes coéquipiers. J'étais confus et je n'arrêtais pas de me demander: 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 de nombreux articles sur comment travailler en tant que concepteur à 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 ils ont officialisé leur processus en l'écrivant . Après avoir lu tout ce matériel, je me suis demandé comment les développeurs étaient confrontés à ce même problème? Comment collaborent-ils sur des environnements distants de manière presque 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 assez bien pour eux: il s'appelle pull requests .

Les demandes d'extraction vous permettent d'introduire des changements 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 à toutes les normes et connexions que le code a déjà en place. C'est exactement ce que j'avais besoin de réaliser, mais bien sûr dans une approche design-mode. Permettez-moi de vous présenter le document de conception de produit

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 document unique qui peut être partagé avec n'importe qui dans votre entreprise et qui vivra comme une connaissance base pour les décisions de produits que vous prenez. Ça a l'air cool, hein? Explorons les détails:

Concepts généraux

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

Grand aperçu )

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

• Contexte est ce que les autres personnes besoin de 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 atteindre.

• Les étapes sont les différentes itérations de votre conception, qui commencent généralement à se concentrer sur la solution plus large et à chaque étape en 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. C'est une manière structurée d'atteindre un point final où les problèmes résolus ne peuvent plus apparaître.

• Feedback fait référence à tous les avis, commentaires, demandes et recommandations que vous avez recueillis 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, n'a pas à fonctionner dans de la même manière pour vous. Mais si vous couvrez ces 4 concepts principaux dans votre PDD, il 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 temps dans cette entreprise. Il comprend les sections suivantes:

• Le Titre doit être concis, clair et facilement distingué des autres titres PDD que vous possédez déjà.
• Le Statut indique à quelle étape se trouve actuellement votre document:
• 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).
• Terminé
  Tous les commentaires ont été traités et il n'y a aucun point manquant. Le PDD est terminé.
• Le Résumé est la description du problème pour lequel vous devez concevoir et renvoie généralement à d'autres lectures connexes utiles que vous pourriez avoir.
• 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 à ce stade que la solution proposée pourrait adopter une approche totalement différente et un retour d'information majeur devrait se produire.
• S60 (ou Stage 60% ) est votre solution à 60% d'exhaustivité et applique les commentaires de S30. Il contient moins de détails que le S90, mais indique clairement l'intention de votre solution. Vous fournissez une structure filaire 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 le stade qui a la solution à 90% d'exhaustivité et applique les commentaires 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 nommage des étapes? Eh bien, non, non. Vous pouvez renommer la scène de S30, S60 et S90 en seulement: Exploration, Proposition, Solution.

Vous pouvez également modifier l'ordre de sorte que le travail le plus raffiné (S90, Solution) arrive en haut du document et le flux de lecture va de la dernière étape à 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. Rappelez-vous: les conventions de dénomination des sections sont totalement personnalisables. Si vous n'aimez pas Abstract utilisez simplement Brief About ou tout ce qui répond à vos besoins. Le concept principal que vous devrez conserver est de 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.

Principaux avantages de l'utilisation de PDD

1. Chaque décision est
   Cela signifie que même lorsque vous quittez votre entreprise / projet (et cela se produira 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 là où vous avez quitté .

2. Améliore la communication.
   Demander à différentes personnes de votre équipe sur le PDD de fournir 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 interminables des parties prenantes.
   Tous stage se concentre sur un angle différent du problème, allant de solutions plus larges à des solutions plus étroites. Cela permet aux gens de se concentrer sur un seul problème à la fois, les aidant 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 l'ingénierie, la conception et d'autres équipes s'engager avec la solution qui en fait partie.

Notes finales

Clôturant l'histoire de cette société distante, je suis arrivé à y travailler pendant quelques mois et j'ai pu implémenter les documents de conception de produits au moins sur 5 projets différents . Ma frustration s'est beaucoup réduite et j'ai pu parvenir à un consensus sur mes propositions de design afin que le produit continue d'évoluer. Depuis, 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 que Abstract créait un product 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 encore un sujet assez pertinent.

Bibliographie

(vf, yk, il) [19659068]

Le meilleur outil 2023 pour ta croissance Instagram !

Source link

Partager :

• Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
• Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)

Articles similaires