la route la moins fréquentée.Les avantages du changement « Continuer à expédier les choses » est parfois un piège qui vous donne l'illusion qu'aucun changement n'est nécessaire. Il arrive souvent, cependant, que vous vous rendiez compte qu'il existe de meilleures façons de travailler une fois que vous aurez commencé à rendre votre processus plus efficace, évolutif et durable. Vous pouvez expérimenter en essayant d'optimiser et de réduire les étapes les plus fastidieuses de votre flux de travail, celles qui prennent plus de temps ou vous distraient des choses que vous voulez vraiment faire. À ce moment-là, vous commencerez à vous demander pourquoi vous ne l'avez pas fait avant. Ce aha ! moment peut être une réalisation de soi au début, mais une fois que vous l'aurez compris, vous pourrez en présenter les avantages aux autres membres de votre équipe. Jusque-là, vous devrez peut-être travailler par vous-même dans l'ombre, en préparant silencieusement votre cas. des pratiques de conception qui amélioreront la collaboration entre les équipes. Des pratiques qui, dans le meilleur des cas, commenceront à changer l'état d'esprit de chacun une fois qu'ils commenceront à "voir la lumière" eux-mêmes. On s'apercevra de la nécessité d'aller de l'avant lorsque les avantages du procédé seront évidents puisque toute l'équipe en bénéficiera.
( Grand aperçu ) Mais je ne parle pas ici de systèmes de conception. Commençons simplement : pensez d'abord aux choses les plus simples. Par exemple, il suffit de nommer un composant de la même manière dans la conception et le code ; ou faire un peu de travail préparatoire en spécifiant la largeur maximale d'un conteneur et comment il réagira à des quantités variables de contenu, des choses qui tôt ou tard devront être traitées de toute façon. Si c'est bien fait, commencer par la phase de conception et avec la participation des ingénieurs facilitera la mise en œuvre plus tard. Définissez les interactions, les animations et les transitions ensemble – vous pouvez créer un prototype de base qui apportera un alignement supplémentaire et renforcera la confiance de chaque membre de l'équipe, avant même qu'une seule ligne de code ne soit écrite.
Et il y a autre chose. En tant que concepteurs, nous devons soutenir nos collègues membres de l'équipe, actuels et futurs, qui devront travailler sur nos fichiers de conception et comprendre comment nous sommes arrivés à ces résultats. Le travail de conception devrait être assez explicite.
Mais nous le ferons également pour nous-mêmes, afin de pouvoir prendre des décisions de conception plus réfléchies. S'arrêter un instant pendant ce processus de réorganisation nous forcera à repenser comment nous avons fait les choses jusqu'à présent, et pourquoi. Nous avons tendance à oublier que le processus d'organisation de notre conception est aussi du design – être organisé, efficace, optimiser les ressources afin d'obtenir plus de solutions possibles. Le processus que nous suivons n'est-il pas quelque chose qui nous façonne également en tant que concepteurs, au-delà du résultat final ? Certaines équipes peuvent avoir besoin d'incertitude et même d'un certain désordre pour prospérer. Il se peut que cela n'ait pas beaucoup de sens d'imposer un certain ordre et des conditions alors que c'est précisément l'absence de ceux-ci qui permet à des propositions plus riches de germer et de se développer pendant la phase d'exploration.
Peut-être que cette approche chaotique ne fonctionne pour vous que pour certaines parties du processus de conception et c'est vous qui devrez décider de la quantité à autoriser. Il y a un seuil où l'on peut manœuvrer en gardant un équilibre pendant que vous explorez et suivez certains bons flux de travail en même temps. Si dernièrement, vous perdez la plupart de votre temps à comprendre le fonctionnement d'un design ou à rechercher des pièces du passé, il est probable que vous ayez déjà franchi cette ligne.
Les étapes du processus Il y a certaines étapes que vous mettre en pratique pour amorcer ce changement. Il y a beaucoup de battage médiatique autour des systèmes de conception (et bon, même j'ai créé un cours en ligne à leur sujet !) Pourtant, il n'est même pas nécessaire d'avoir un tel système et d'adopter un flux de travail que vous pouvez répliquer sur n'importe quel vous et votre équipe le ferez à partir de maintenant.
Cependant, il existe une façon stratégique de commencer à travailler là-dessus afin que cela ne représente pas trop de tracas. Vous pouvez, par exemple, attendre qu'il soit nécessaire de concevoir un nouveau composant et le faire ensuite seulement. Commencez à mettre cette nouvelle approche en pratique plus régulièrement et préparez le terrain pour le reste du travail de conception, futur et passé. plus évident, j'espère que d'autres personnes de votre équipe verront cela comme la référence à viser. Alors ne devenez pas fou en appliquant cela à tout ce qui se trouve dans votre produit jusqu'à ce que vous voyiez des signes que les gens sont d'accord avec l'idée. La documentation jouera un rôle clé dans ce processus (comme nous le verrons plus tard) car ce sera un élément de communication qui servira également de success story pour les non-designers.
Une fois les premiers pas franchis. fait, il est probable qu'il n'y aura aucun argument pour ne pas reproduire ce processus pour d'autres choses que vous ferez à partir de maintenant, et même avec des conceptions précédentes qui ont été livrées sans suivre cette technique.
Alors , comment pouvez-vous lancer cela avec votre prochain nouveau composant d'interface ? Commençons par le concept de modularisation .
Modularisez des parties de la conception Dès le début d'un nouveau projet de conception (après une conception exploratoire et des recherches), vous pouvez commencer à penser de systématiser vos conceptions. Une façon de faire est de penser à des propriétés de pseudo-conception qui pourraient plus tard être en corrélation avec celles que vous aurez dans le code. Par exemple, pour un nouveau composant, quels sont les aspects de celui-ci qui, selon vous, devraient être personnalisables par instance ultérieurement ? Il peut s'agir de parties du contenu ou de propriétés visuelles.
Conseil utile : Attention, des logiciels tels que Figma offrent aux concepteurs une grande liberté pour modifier les éléments dans les instances des composants . Ces changements, plus tard, seront difficiles à reproduire par un ingénieur utilisant la contrepartie codée du composant. C'est pourquoi votre définition de conception devrait déjà inclure des tables (ou quelque chose de similaire qui fera l'affaire) dans le fichier de conception lui-même, indiquant quelles sont les propriétés qui seront flexibles pour être modifiées ultérieurement. Cela sera utile pour les concepteurs, mais aussi pour les ingénieurs, car ils auront une idée approximative de la façon de structurer les données lorsque la phase de mise en œuvre proprement dite commencera.
La façon dont vous présentez et communiquez votre proposition de conception doit également refléter ces décisions d'une manière très claire, d'un point de vue visuel. Organisez votre conception de manière à ce qu'il soit évident qu'elle est divisée et structurée en variantes, simplement en y jetant un coup d'œil.
Validez avec les ingénieurs Une grande partie de tout ce processus consiste à s'assurer que le la proposition de conception et les dispositions de ces modules ont également du sens pour les ingénieurs. Cela se traduira par une certaine parité et un alignement entre le composant conçu et son homologue codé.
Pendant la phase de validation, les ingénieurs examineront probablement ce que vous avez, poseront des questions (beaucoup, espérons-le, c'est bon signe !) , afin que vous puissiez mieux affiner les scénarios éventuellement absents de vos variantes. Ceux-ci peuvent inclure des états de chargement ou intermédiaires, ou des conceptions avec des quantités variables d'informations (trop peu ou trop). Ces questions aideront à déterminer dans quelle mesure la conception du composant est bien préparée pour les conditions du monde réel.
Un autre point important est qu'à ce stade, les concepteurs doivent trouver des moyens de s'aligner sur les ingénieurs en ce qui concerne la façon dont ces propriétés nous avons mentionné sont nommés. Idéalement, la façon dont vous divisez un composant dans votre logiciel de conception devrait suivre une logique similaire à ce qui se passe dans le code et la même chose avec la façon dont ces propriétés sont nommées.
Il est important de rapprocher les concepteurs d'une méthode systématique de la pensée ; cet alignement est ce qui rendra tout ce travail durable dans le temps.
Documentation La bonne chose à propos de tout ce travail que nous (ou vous, encore mieux) avons fait jusqu'à présent, c'est qu'il servira un objectif au-delà de la phase de validation et jettera les bases d'une documentation plus permanente. Vous souvenez-vous de ce dont je parlais au début, faciliter les choses pour les nouveaux arrivants ? Ils n'auront pas besoin de comprendre les allers-retours qui ont eu lieu pour valider un composant. La documentation sera plutôt le témoignage et le résultat de cette friction pour eux.
Si nous parlons uniquement de composants, il y a quelques éléments que vous pourriez inclure dans la documentation :
Propriétés . Même si la documentation est orientée design et qu'il existe une documentation technique séparée, il sera utile d'inclure une liste simplifiée des propriétés que le composant codé autorisera et pourra être personnalisé avec. C'est principalement pour les concepteurs qui doivent comprendre que dans leur logiciel de conception (où les choses sont plus faciles à changer, par rapport aux choses qui peuvent être modifiées dans le code), ils ne peuvent pas simplement changer tout ce qu'ils veulent – mais doivent plutôt suivre un ensemble de règles prédéfinies.
Variantes. Toutes les variations visuelles (et comportementales) qu'un composant peut avoir. Il peut s'agir de différentes tailles, d'exemples avec ou sans icônes, et de tous ses différents états (survolé, focus, enfoncé, désactivé, etc.).
Cas d'utilisation. C'est toujours une bonne idée de documenter comment le composant sera utilisé dans son contexte et pas seulement de manière isolée. En montrant des exemples du composant dans un scénario réaliste qui existe actuellement (ou potentiellement) dans le produit, il sera plus facile pour les gens de comprendre quelle est l'utilisation prévue du composant.
Bonnes pratiques. Ceci l'un est assez simple et signifie essentiellement inclure des recommandations sur la façon dont les gens devraient (et ne devraient pas) utiliser un composant. Il est toujours préférable d'accompagner un composant d'exemples visuels pour montrer ce que vous voulez dire exactement. Certaines choses que vous pourriez inclure sont liées au placement, au contenu, à la personnalisation des propriétés, etc., afin de montrer à la fois les utilisations incorrectes et celles recommandées.
Conception du contenu. En commençant par phase de conception, vous pouvez commencer à réfléchir à la manière dont le contenu textuel du composant doit être utilisé. Pensez aux bonnes pratiques et approches pour les étiquettes, les espaces réservés, comment écrire des messages d'erreur et du texte dans les boutons. Il n'est pas nécessaire d'entrer dans les détails ; pensez simplement aux situations les plus courantes à garder à l'esprit, puis énumérez-les une par une.
Notes sur le comportement et l'interaction. Cela affecte nécessairement la proposition de conception mais peut être utile pour comprendre comment le composant fonctionne dans différentes circonstances. Semblable à ce que nous avons mentionné précédemment lors de la phase de validation avec les ingénieurs, vous pouvez inclure des exemples de la façon dont un composant s'adapte en fonction de la quantité de contenu dont il dispose ; soit une représentation de la zone d'interaction (la zone qui sera cliquable) ; et ainsi de suite.
Il y a quelques autres choses que vous pourriez inclure, en plus de tout cela. Si vous avez la possibilité d'intégrer également des prototypes ou de vrais exemples codés, cela aidera à brosser le tableau d'ensemble et les concepteurs qui consultent la documentation auront une idée plus qu'approfondie du composant, de son fonctionnement dans le produit, comment l'utiliser et ce qu'il est possible d'en faire. contenu que vous pensez que la plupart des composants devraient avoir pour être clair et facile à comprendre. Tout cela est plus que quiconque voudrait commencer à travailler sur un produit.
Reproduire le processus avec des conceptions plus anciennes Si et quand vous avez réussi à défendre ce processus, les gens voudront très probablement suivre une approche similaire à partir de maintenant. Les conceptions qui ont déjà été expédiées et qui peuvent nécessiter une maintenance ou des améliorations ne seront qu'une autre chance de commencer à appliquer ce nouveau flux de travail dans votre pratique quotidienne.
Dans ce cas, en plus de suivre les étapes mentionnées précédemment, vous aurez besoin faire un travail supplémentaire pour apporter un alignement supplémentaire. Une bonne idée serait de commencer à faire un auditif de toutes les différentes instances d'un composant particulier, dans les fichiers de conception et dans les versions implémentées dans le produit. Vous commencerez peut-être à remarquer des écarts entre la conception et la mise en œuvre – ou peut-être qu'une conception n'a même jamais été mise en œuvre – ou peut-être découvrirez-vous qu'il existe de nombreuses versions différentes. composant, indépendamment, en rassemblant le tout dans une seule toile dans le seul but de collecter, d'observer et de comparer. Vous pouvez commencer avec quelque chose d'aussi simple qu'un bouton, un champ de saisie ou un pied de page, et mapper toutes les versions de ces éléments que vous avez trouvées dispersées. Une fois que vous avez tout au même endroit, vous pouvez commencer le processus de nettoyage : supprimer et simplifier tout ce qui est légèrement différent dans un but de consolidation et d'unification. Au lieu d'avoir 34 boutons qui semblent légèrement différents, gardez-en quelques-uns qui semblent plus distinctifs.
À partir de là, vous pouvez relier cette partie du travail à ce que nous avons mentionné précédemment. Cela signifie commencer par structurer les composants sur un ensemble similaire de variantes et de propriétés à celles que vous avez suivies pour les nouveaux composants. En fin de compte, ils ressembleront tous à une famille, ou… oui, un design système .
Du système à l'état d'esprit En parlant de systèmes, ce que personne ne vous dit concernant les systèmes de conception, c'est que la partie de la croissance, du maintien et de la diffusion de la voix est plus difficile que la partie de la conception et du codage des composants. Et vous devrez faire ces choses tous les jours !
Les choses que nous avons examinées jusqu'à présent ne vous obligent même pas à avoir un système de conception en soi. Vous pouvez adopter la plupart de ces techniques même si c'est uniquement pour la partie design du produit. Si vous le faites, vous commencerez à changer votre état d'esprit. Ainsi, lorsque vous aurez la possibilité de travailler ou de démarrer un système de conception, vous serez plus que prêt à ce moment-là.
Changer votre façon de travailler et adopter des pratiques conformes à la modularité, la réutilisabilité, l'évolutivité et quelques autres mots *-ity vous aideront à rendre votre travail de conception durable dans le temps.
( Grand aperçu ) En cours de route, vous devrez également éduquer les autres – mais une fois que vous aurez adopté une méthodologie qui convient à votre équipe, à votre contexte et à vos besoins, et si ses avantages sont clairs, d'autres suivront et cet état d'esprit commencera à se répandre et se propager en interne jusqu'à ce que cela devienne une pratique établie.
Avec les designers, il y aura un travail supplémentaire, car, contrairement aux ingénieurs, nous ne sommes pas tellement habitués à penser en termes de propriétés et de modularité, et pouvons nous sentir contraints par le manque de personnalisation qu'un composant particulier peut avoir. Cela ne changera probablement pas du jour au lendemain, mais vous pouvez commencer à adopter certaines pratiques qui, petit à petit, aideront les concepteurs à apprendre à travailler de manière plus systématique et plus efficace.
Ce ne sont que quelques-unes des pratiques. pour n'en citer que quelques-unes :
Suivez les conventions internes. Il n'y a pas une seule façon de faire les choses, et généralement chaque concepteur a ses propres flux de travail. C'est pourquoi il est important de s'entendre sur les bases – de la dénomination des calques à la répartition des variantes des composants dans votre logiciel de conception – d'une manière qui puisse être rapidement comprise par tout le monde. Le but ultime serait d'ouvrir un fichier de n'importe quel autre concepteur de l'équipe, le fichier devrait avoir un sens à première vue, et en comprenant sa logique, vous devriez pouvoir facilement travailler avec et le modifier. Cela va au-delà des fichiers de conception eux-mêmes. Vous pouvez également suivre des flux de travail standardisés sur la façon de concevoir des composants, de communiquer une version de produit ou de gérer les bogues dans la conception. Il est important de s'assurer que tout le monde est d'accord avec cela et d'avoir une documentation publique pour renforcer ces directives. (Cela ne fonctionnera pas si seulement quelques personnes dans l'équipe les suivent, et le reste s'en moque.)
Pensez à la modularité dès le début. Comme mentionné précédemment, vous ne Il n'est pas nécessaire d'attendre d'avoir un composant implémenté pour déterminer ses variantes et ses propriétés. Vous pouvez commencer à planifier ces choses pendant la phase d'exploration de la conception. Juste en gardant à l'esprit ce qui pourrait être une propriété personnalisable dans le composant final, vous vous adapterez pour travailler d'une manière plus pragmatique qui vous fera gagner du temps et des allers-retours avec les ingénieurs de votre équipe .
Au cours de cette étape, vous pouvez impliquer d'autres personnes pour valider vos idées et obtenir des commentaires afin qu'elles connaissent votre proposition de conception avant même qu'elle ne soit dans sa forme finale, et en même temps, votre conception ne sera pas complète surprise quand vient le moment d'obtenir une validation plus officielle.
Ne vous faites pas prendre par votre outil de conception. Chaque outil de conception a des contraintes qui nous font involontairement augmenter l'écart entre la conception et le code. Dans certains cas, nos outils de conception vont même nous forcer à faire des choses d'une certaine manière qui n'aura pas de parité dans le code. C'est pourquoi il est important de se demander de temps en temps : « Le logiciel que nous utilisons est-il une limitation ou est-il utile ? Cela nous aide-t-il à obtenir de meilleurs résultats ou nous gêne-t-il ?" utilisez Figma, Sketch, Illustrator, Affinity Designer ou Microsoft Paint pour le concevoir. La documentation est une autre étape du processus et elle ne doit pas être négligée. Ce sera un résumé et un témoignage du fonctionnement de quelque chose, mais aussi un document vivant qui changera et évoluera avec le temps, comme n'importe quel élément de la conception. Mais documenter pour la documentation n'est pas très utile, il doit servir un objectif avec des avantages clairs pour les équipes de conception et de développement. Je pense que c'est pourquoi, en plus d'être utile, vous devez rendre la documentation claire, visuellement bien expliquée et aussi conviviale que possible. cela signifie que vous avez déjà expliqué certains cas d'utilisation et différents scénarios. Ainsi, au lieu de devoir constamment les créer/concevoir à chaque fois, vous pouvez simplement vous référer à la documentation. C'est assurément un moyen de gagner du temps et d'éviter de redéfinir à chaque fois les comportements à partir de zéro. Par exemple, si vous avez un modèle pour un processus de recherche dans votre documentation de conception, cela signifie que dans l'écran de l'interface utilisateur où vous avez un champ de saisie de recherche, vous pouvez simplement mettre le champ de recherche et oublier de le spécifier à nouveau. Paresse efficace pourrait-on dire.
Une autre façon de concevoir moins consiste à tirer parti des propriétés des composants. Cela vous permettra d'ignorer les conceptions répétitives où la seule chose qui change sont les valeurs des propriétés mais pas la conception visuelle elle-même. Pensez à une boîte de dialogue modale qui permet de personnaliser le titre, le texte et les boutons, tandis que tout le reste reste le même. Chaque fois que vous avez besoin de les utiliser, au lieu de concevoir un plein écran pour afficher uniquement les valeurs des propriétés, vous pouvez les documenter séparément sous forme de texte simple. À long terme, un tel système sera plus facile à maintenir et sera plus proche de ce dont un ingénieur a besoin pour le mettre en œuvre.
Mettre en place un processus de maintenance et de contribution. Tout ce que nous avons mentionné jusqu'ici sera aussi utile que sa capacité à évoluer dans le temps. Vous devrez peut-être définir certains rôles pour indiquer clairement qui est en charge de la maintenance de quoi. La propriété maintiendra les processus, la documentation et les composants légers, efficaces et organisés. Il pourrait y avoir différentes façons de gérer cela, mais je préfère une approche où il y a quelqu'un responsable de chaque partie – cela pourrait être n'importe qui au sein de l'équipe. De cette façon, ils sentiront que c'est leur responsabilité et agiront en tant que gardiens et éducateurs pour que le travail continue de servir son objectif initial et reste en bon état. être également responsable d'intégrer les nouvelles contributions et suggestions d'autres concepteurs moins impliqués. À cet égard, il est important d'être transparent sur vos critères d'acceptation et d'ajout de toute nouvelle pièce, des modifications mineures apportées à la documentation aux nouveaux composants. Les contributeurs (qui peuvent être n'importe qui dans l'équipe) devront comprendre qu'il s'agit d'un processus qui vise à maintenir la barre de qualité, mais en même temps ne se sentira pas décourageant ou « bureaucratique » pour les contributeurs. Gardez-le simple et maigre, comme tout le reste. Testez-le et affinez-le au fil du temps, mais ne vous contentez pas de ce que vous pensez "fonctionner juste". ] Grand aperçu )
Conclusion Indépendamment de la mise en place d'un système de conception, il vaut la peine d'investir du temps pour structurer correctement les workflows de conception et favoriser les bonnes pratiques qui peuvent être maintenues dans le temps. Cela accélérera votre processus de conception, les nouveaux arrivants auront besoin de passer moins de temps à comprendre comment tout fonctionne, et ils augmenteront l'alignement et la collaboration entre les concepteurs et les ingénieurs.
Et plus important encore, la promotion de bonnes pratiques de conception peut également aider les concepteurs à changer leur état d'esprit – d'une certaine manière, cela semble plus strict et rigide, mais cela défiera en fait leur créativité et aidera à générer des résultats efficaces basés sur des propriétés réutilisables, plus proches des contraintes des composants codés.
Changer la culture interne et obtenir. l'adhésion interne ne se fera pas du jour au lendemain. It may involve a lot of work, convincing people, and even working in the shadows before you have a proposal that can be shared, agreed upon, and put in place to see if it sticks.
And as with everything, it may need iterations over time and little tweaks to see if it works for your particular needs (and your particular team). Although it sounds daunting, give it a try! I’m sure you will be a better designer at the other side of tunnel — and hopefully, the rest of your team as well.
(mb, vf, yk, il)