Parfois, il faut dire poliment "non"

Nov 26 2022
Les rejets argumentatifs font partie du travail de création et de maintenance des systèmes de conception.
Il existe un grand nombre d'articles qui enseignent comment les concepteurs peuvent dire non. Il s'agit principalement de pigistes et de la façon d'interagir avec des clients difficiles.
Générique — Effet néon par Valery Zanimanski

Il existe un grand nombre d'articles qui enseignent comment les concepteurs peuvent dire non . Il s'agit principalement de pigistes et de la façon d'interagir avec des clients difficiles. Il existe également des articles contenant des conseils pour traiter avec les chefs de produit. Cependant, qu'en est-il lorsque vous prenez en charge un système de conception ? Que faire des demandes conflictuelles d'autres concepteurs ou développeurs ?

Je ne sais pas encore ce que je fais...

Si vous n'êtes pas un expert et que vous commencez tout juste à créer un système de conception pour votre entreprise, vous ne savez peut-être pas quelle direction prendre. Vous pouvez, bien sûr, lire plusieurs articles avec des recettes sur " comment commencer ", mais parfois il n'y a rien de mieux que l'expérience personnelle. Essayer quelque chose, faire des erreurs parfois et apprendre de ses erreurs. Être ouvert à de nouvelles choses. Soyez une personne « Oui, essayons ».

Vous devez être aussi flexible que possible dans une telle situation. Cependant, documentez vos décisions si vous ne voulez pas que les décisions réussies restent de la "magie noire" et que celles qui échouent restent une coïncidence inconnue.

Je ne veux pas seulement dire par écrit la décision elle-même, mais comment vous (ou d'autres) y arrivez. Arguments, etc. Oui, cela peut être parfois difficile. Surtout quand la décision était intuitive (intuition). Cependant, si vous apprenez à vous remettre en question et à remettre les autres en question, vous pourrez éventuellement commencer à comprendre la source de l'idée.

Giphy Source

Une telle documentation vous permettra de mieux comprendre les relations de cause à effet et d'apprendre ce qui fonctionne et ce qui ne fonctionne pas. Et la prochaine fois, si vous voyez qu'une nouvelle proposition correspond à un modèle connu (ou va dans le même sens), vous pourrez le signaler aux autres. Autrement dit, vous apprendrez à donner des raisons motivées contre des solutions risquées.

J'ai déjà vu ça quelque part...

Vous pouvez toujours demander à la communauté des exemples lorsqu'il s'agit de mauvaises décisions . Les designers (et de nombreuses autres professions) aiment faire des listes de ce qu'il ne faut pas faire .

Il existe un large éventail d'articles dans la catégorie " 10 pires décisions de conception ", etc. Cependant, concernant les systèmes de conception, les plus importants seront les descriptions des "Bonnes/Mauvaises" pratiques, "Patterns", "Do's & Don'ts", etc. Et il est préférable de les rechercher dans la documentation des systèmes de conception ouverts.

Source Material.io

Souvent , ces documents fournissent des arguments concis mais concis pour ou contre une solution particulière, et ils peuvent grandement aider à analyser les situations qui surviennent dans votre système. Et même dans votre travail de conception quotidien.

Les « choses à faire et à ne pas faire » sont un élément clé de toute documentation de conception de système et plus tôt vous commencez à documenter les « bonnes/mauvaises » pratiques pour votre système, plus vous serez en mesure d'éviter les questions et les malentendus.

« Si ce n'est pas documenté, ça n'existe pas »

La documentation est un engagement. Mais aussi des conseils sur « que pourrais-je/devrais-je faire ». Après tout, les concepteurs prennent souvent des décisions discutables parce qu'ils ne savent pas ce qui doit et ne doit pas être fait dans le système de conception. En son absence, l'énoncé « tout est possible » est une pensée raisonnable.

Mais ici, il est important de souligner : la documentation n'est pas une question d'interdiction. La documentation est conçue pour expliquer le fonctionnement du système et indiquer raisonnablement ce qui vaut la peine d'être fait et ce qui ne l'est pas. Par conséquent, si le concepteur (ou le développeur) n'est motivé que par "j'aime ça comme ça" et que cela contredit la documentation - vous avez une raison raisonnable et justifiable de refuser, en vous référant à la documentation.

La documentation aide à donner le bon exemple aux autres pour défendre leurs idées. Et transformez les idées en solutions qui vous aideront à faire passer votre système de conception au niveau supérieur.

Bibliothèque de conception ≠ Système de conception

Souvent, des problèmes surviennent lorsque les utilisateurs (ou contributeurs) ne comprennent pas ce qu'est un système de conception et le considèrent comme une bibliothèque de conception. De nombreux concepteurs ont l'habitude de traiter avec des bibliothèques de conception prêtes à l'emploi et d'avoir à les modifier pour répondre à leurs besoins.

"J'aime ce kit d'interface utilisateur, mais il a été créé sans aucune considération pour mes cas d'utilisation et j'ai donc besoin de le personnaliser". Cela semble assez raisonnable, n'est-ce pas? Oui, s'il s'agit de solutions tierces dont vous (ou quelqu'un d'autre) n'utiliserez qu'une petite partie. Mais dans le cas d'un système de conception interne, cela pourrait conduire au chaos.

Quelque chose de similaire, mais un peu différent….

À mon avis, le plus difficile est lorsque les utilisateurs demandent de petits changements. De tout petits changements :

  • Ajoutez la possibilité d'utiliser des icônes dans les en-têtes.
  • Modifiez l'ordre des blocs dans la liste.
  • Afficher 3 boutons au lieu de 2 (définis par un composant).
  • Cohérence de l'approche avec les autres composantes.
  • La complexité de mise en œuvre dans le code et les composants de conception (Figma, Sketch, etc.).

Tout d'abord, vous devez déterminer si le motif croise un autre composant. Pour ce faire, vous devez soit connaître tous les composants et leur comportement par cœur, soit parcourir chacun d'eux et voir si la proposition est en conflit avec l'un des autres composants. S'il y a le moindre conflit, il est nécessaire de discuter de la proposition non pas isolément, mais dans le contexte du comportement de plusieurs composants. Cela peut souvent nécessiter d'inviter plus de personnes dans la discussion.

La complexité de la mise en œuvre

Très souvent, ce qui ressemble à une solution simple dans la conception peut nécessiter un énorme effort de développement. Peut-être parce que l'architecture actuelle n'est pas assez flexible. Peut-être que cela va simplement à l'encontre des normes/approches de base utilisées dans le développement. Théoriquement, presque tout est possible, mais certaines choses nécessiteront plus d'efforts. Dans une telle situation, vous devrez peut-être comprendre à quel point ces changements sont importants : « Agréable à avoir » ou « Besoins critiques ».

Nous sommes des serviteurs, pas des dictateurs

Le système de conception est un produit . Mais c'est très spécifique. Alors que le succès de la majorité des produits peut être mesuré par le montant d'argent qu'ils rapportent, pour un système de conception, l'indicateur principal est le nombre d'utilisateurs qui l'utilisent et à quel point il leur facilite la vie. En d'autres termes, un système de conception est "Le produit le plus honnête" . Et cela implique beaucoup de responsabilités. Nous ne devons pas seulement tirer le meilleur parti de ce que veulent les clients, mais aussi les aider à comprendre les conséquences de chaque décision douteuse :

  • un manque de souplesse dans la perspective
  • retards dans le développement de la solution (en raison de la complexité de la solution et de sa maintenance)
  • la nécessité d'apporter des modifications en cascade à d'autres composants ou accords
  • Contributions au système de conception de l'intendance

En fin de compte, le système de conception concerne les utilisateurs (concepteurs et développeurs). Il faut donc être très attentif à eux. Après tout, sans eux, nous ne sommes personne. Et si les modifications sont raisonnables et ne cassent rien, pourquoi ne pas les faire ?

Toutes les raisons de dire « non » consistent simplement à s'assurer que nous créons le produit dont les utilisateurs ont besoin, et non celui qu'ils veulent.

Interrogé sur l'apport des clients dans le développement du Ford Model T, Henry Ford a déclaré: "Si j'avais demandé aux gens ce qu'ils voulaient, ils auraient dit des chevaux plus rapides."

Merci d'avoir lu! Restons en contact! Connectez-vous avec moi sur LinkedIn et suivez-moi sur Dribbble et ici sur Medium pour plus de contenu lié au design.