Les systèmes de conception concernent les relations

Les systèmes de conception peuvent être incroyablement utiles. Ils fournissent des éléments réutilisables et des lignes directrices pour créer une « apparence et une convivialité » cohérentes pour tous les produits. En conséquence, les utilisateurs peuvent prendre ce qu'ils ont appris d'un produit et l'appliquer à un autre. De même, les équipes peuvent déployer des modèles bien testés pour la navigation ou les avis, rendant les produits plus fiables. Des systèmes de conception efficaces résolvent des problèmes ennuyeux de manière reproductible afin que les développeurs et les concepteurs puissent se concentrer sur la résolution de nouveaux problèmes.

Pourtant, lorsque quelqu'un utilise le terme « système de conception » lors d'une réunion, je ne sais jamais vraiment à quelle réaction s'attendre. J'ai vu de la curiosité et de l'enthousiasme à l'idée d'essayer une nouvelle façon de travailler, mais j'ai aussi vu de la frustration et de l'inquiétude à l'idée d'un système limitant la créativité des designers. Certains concepteurs affirment que les systèmes de conception sapent la créativité ou qu'ils sont des solutions à la recherche d'un problème. Les systèmes de conception peuvent se fragmenter au fil du temps, obligeant les équipes à ne plus les utiliser.

Les systèmes de conception ne vont pas disparaître, cependant. Selon une enquête, seulement 15 % des organisations ne disposaient pas d'un système de conception en 2018. C'est en baisse par rapport à 28% l'année précédente. Certaines équipes utilisent de grands systèmes de conception à usage général tels que Material Design de Google, tandis que d'autres utilisent des systèmes plus petits et plus personnalisés tels que Cedar de REI et Protocol de Mozilla.

Les systèmes de conception doivent responsabiliser les équipes, pas les limiter. Pour que cela se produise, nous devons commencer à penser de manière plus holistique. Un système de conception n'est pas seulement du code, des conceptions ou de la documentation. C'est tout cela, plus les relations entre les gens qui font le système et ceux qui l'utilisent. Cela inclut non seulement les fichiers CSS et les documents Sketch, mais également la confiance, la communication et la propriété partagée. Il s'avère qu'il existe tout un domaine d'étude dédié à l'exploration de systèmes comme ceux-ci.

La grande image

Un article de 1960 intitulé "Systèmes socio-techniques" a exploré les interactions entre la technologie, les humains et l'environnement plus large dans lequel ils existent. Enid Mumford a expliqué que les chercheurs ont commencé par étudier comment établir de meilleures relations entre les gestionnaires et les employés, mais dans les années 1980, ils se sont concentrés sur l'amélioration de l'efficacité et de la rentabilité du travail. En 2011, Gordon Baxter et Ian Sommerville ont écrit que cette recherche avait contribué à inspirer la conception centrée sur l'utilisateur et qu'il restait beaucoup de travail à faire.

Baxter et Sommerville ont fait valoir qu'il existe encore aujourd'hui une tension entre la recherche « humaniste », centrée sur la qualité de vie des salariés, et la recherche « managériale », centrée sur leur productivité. Ils ont également expliqué qu'il est important de prendre en compte à la fois la technologie et les interactions humaines : "la performance du système repose sur l'optimisation conjointe des sous-systèmes techniques et sociaux".

Je dirais que les systèmes de conception sont des systèmes socio-techniques. Ils impliquent des interactions entre les personnes qui créent le système, les personnes qui créent des produits à l'aide du système et les utilisateurs finaux qui interagissent avec ces produits. Ils évoquent également la même tension entre efficacité et humanisme que Baxter et Sommerville ont vue.

Les systèmes de conception ne sont pas composés uniquement d'images et de code ; ils impliquent des conversations entre concepteurs, développeurs, chefs de produit, PDG et personnes aléatoires sur GitHub. Ces interactions se produisent dans divers contextes - une entreprise, une communauté open source, une maison - et elles se produisent à travers les cultures et les frontières organisationnelles. Construire une équipe peut signifier rassembler des personnes issues de disciplines telles que l'animation, la conception sonore, la visualisation de données, l'haptique et la rédaction. La création d'un système de conception réussi nécessite des parts égales d'expertise technique et de compétences générales.

Et pourtant, parcourez les agrégateurs de nouvelles de conception ou d'ingénierie et vous verrez probablement un accent particulier sur ce «sous-système technique» - code et outils, plutôt que sur les personnes et les conversations. Quel outil créatif est le meilleur pour garder une trace des jetons de conception ? Quelles technologies JavaScript devraient être utilisées pour créer des composants réutilisables - React, des composants Web ou autre chose ? Quel outil de construction est le meilleur ?

La réponse à ces questions est, bien sûr, "ça dépend !" Qui concevra, construira et utilisera le système ? Quels sont leurs besoins ? Sous quelles contraintes opèrent-ils ? Avec quels outils et technologies sont-ils à l'aise ? Que veulent-ils apprendre ?

Pour répondre à ce genre de questions, Baxter et Sommerville recommandent deux types d'activités :

• Activités de sensibilisation et de prise de conscience
  En savoir plus sur les différentes personnes qui créeront et participeront au système, et partager ces informations à grande échelle.
• Engagement constructif
  Communiquer entre les rôles, créer des prototypes et tenir compte à la fois des aspects techniques et sociaux du système.

Creuser

Début 2019, je faisais partie d'une équipe - appelons-les "l'équipe bleue" - qui construisait un système de conception pour une grande organisation. J'ai facilité des discussions informelles avec cette équipe et "l'équipe verte", qui utilisait le système de conception pour créer une application Web. Toutes les deux semaines, nous réunissions tous les développeurs et concepteurs autour d'une table et parlions de ce que nous construisions et des problèmes que nous essayions de résoudre. Ces chats étaient nos « activités de sensibilisation et de prise de conscience ».

Nous n'avions pas la permission de rendre notre système de conception public, nous avons donc fait la meilleure chose suivante : nous l'avons traité comme un petit projet open source au sein de l'organisation. Nous avons placé le code dans un référentiel auquel les deux équipes pouvaient accéder et avons demandé des contributions. L'équipe bleue était responsable de l'examen et de l'approbation de ces contributions, mais n'importe qui dans l'une ou l'autre équipe pouvait contribuer. Team blue construisait également sa propre application, donc dans un sens, ils étaient à la fois utilisateurs et gardiens du système de conception.

Ces interactions ont aidé les équipes à créer de meilleurs produits, mais tout aussi important, elles ont établi la confiance entre les équipes. L'équipe bleue a appris que les gens utilisaient le système de manière réfléchie et construisaient de nouvelles idées intelligentes par-dessus. L'équipe verte a appris que le système était vraiment adapté à ses besoins, de sorte qu'elle pouvait travailler avec lui plutôt que contre lui. Baxter et Sommerville pourraient qualifier ce travail d'« engagement constructif ».

Nous avons constaté que les deux équipes étaient sous pression pour apprendre de nouvelles technologies et livrer rapidement un produit complet. En d'autres termes, ils fonctionnaient déjà sous une charge cognitive assez considérable. En conséquence, les deux équipes ont convenu de se concentrer sur la facilité d'utilisation du système. Cela signifiait éviter tout le débat sur les composants Web, se concentrer principalement sur CSS et s'assurer que notre documentation était claire et conviviale.

Mettre tous ensemble

Les organisations de toutes tailles créent des éléments de conception réutilisables pour aider les équipes à créer des applications plus cohérentes et élégantes. Les besoins et la dynamique des différentes organisations sont exprimés dans leurs systèmes de conception. Voici quelques exemples :

• Material Design de Google a plusieurs implémentations dans différents frameworks et langages. Il est utilisé par une variété de personnes à l'intérieur et à l'extérieur de Google, il dispose donc d'une documentation complète et d'une variété de boîtes à outils pour les applications de conception.
• Le Fluent Design System de Microsoft cible quatre plates-formes très différentes. Comme Material, il comprend des boîtes à outils pour les concepteurs UX et une documentation complète.
• Le protocole de Mozilla est implémenté en Sass et en JavaScript vanille. Il met fortement l'accent sur l'internationalisation. Alex Gibson dit que ce système aide Mozilla à "créer des pages Web sur la marque à un rythme plus rapide avec moins de travail manuel répétitif".
• Cedar de REI est construit avec des composants Vue.js et ne peut pas être utilisé avec d'autres frameworks JavaScript. Cedar est principalement utilisé par les développeurs internes de REI et est étroitement lié à la marque de l'entreprise. Le code du système de conception est open source, mais ses polices ne le sont pas.
• Lightning Design System de Salesforce est un framework CSS indépendant de JavaScript. Il peut éventuellement être utilisé avec Lightning Component Framework, qui comprend deux implémentations JavaScript : une utilisant des composants Web et une autre utilisant le framework Aura propriétaire de Salesforce.
• PatternFly de Red Hat a été créé pour offrir une expérience utilisateur cohérente sur les produits de la plate-forme cloud de l'entreprise, il a donc une densité d'informations relativement élevée et comprend une variété de composants de visualisation de données. L'équipe PatternFly est récemment passée d'Angular à React après quelques expérimentations avec des composants Web. PatternFly inclut également une implémentation indépendante de JavaScript utilisant HTML et CSS. (Divulgation complète : je suis un ancien chapelier rouge.)
• Le système de conception carbone d'IBM propose des implémentations dans React, Vue, Angular et JavaScript vanille, ainsi qu'une boîte à outils de conception pour Sketch. L'équipe Carbon expérimente des composants Web. (Chapeau à Jonathan Speek pour avoir retrouvé ce référentiel.)

Des systèmes comme ceux-ci sont cohérents et fiables parce que des personnes d'équipes et de rôles différents ont travaillé ensemble pour les construire. Ces systèmes résolvent de vrais problèmes. Ils ne sont pas le résultat de développeurs essayant d'imposer leur volonté aux concepteurs ou vice-versa.

Josh Mateo et Brendon Manwaring expliquent que les concepteurs de Spotify "voient leur rôle en tant que principaux contributeurs et co-auteurs d' un système partagé , dont ils sont propriétaires". Mina Markham se décrit comme "la traductrice entre l'ingénierie et la conception" sur le système de conception Pantsuit. Jina Anne se penche sur la dynamique d'équipe et la recherche d'utilisateurs derrière les systèmes de conception : "Alerte spoiler ! Vous allez avoir besoin de plus que de simples designers.

Construisons des trucs !

Maintenant que nous avons parcouru des recherches et quelques exemples, parlons de la façon de construire un nouveau système de conception. Commencez par parler aux gens. Déterminez qui utilisera et contribuera à votre système de conception. Ces personnes couvriront probablement une variété de disciplines - conception, développement, gestion de produits, affaires, etc. Renseignez-vous sur les besoins et les objectifs des gens et demandez-leur de partager ce sur quoi ils travaillent. Envisagez de planifier une réunion informelle avec des collations, du café ou du thé pour créer une atmosphère accueillante. Établir une communication régulière avec ces personnes. Cela peut signifier rejoindre une salle de discussion partagée ou planifier des réunions régulières. Gardez un ton décontracté et amical et concentrez-vous sur l'écoute.

Lorsque vous parlez de ce sur quoi vous travaillez, recherchez des problèmes et des objectifs communs. Vous constaterez peut-être que les équipes ont besoin d'afficher de grandes quantités de données, elles étudient donc des outils pour afficher des tableaux et générer des rapports. Prioriser les solutions à ces problèmes.

Recherchez également des motifs répétés et des variations sur des thèmes similaires. Vous constaterez peut-être que les boutons et les formulaires de connexion sont un peu différents d'une équipe à l'autre. Quelle est la signification de ces variations ? Quelles variations sont intentionnelles - par exemple, un bouton principal par rapport à un bouton secondaire - et quelles variations se sont produites par accident ? Votre système de conception peut nommer et cataloguer les modèles et variations intentionnels, et il peut éliminer les variations « accidentelles ».

Le but ici est d'établir une boucle de rétroaction rapide avec les personnes qui utilisent le système de conception. Une rétroaction plus rapide et des itérations plus petites peuvent aider à éviter d'aller trop loin dans la mauvaise direction et d'avoir à changer radicalement de cap. PJ Onori appelle ces changements soudains et importants "thrash". Il dit qu'un peu de thrash est bon - c'est un signe que vous apprenez et réagissez au changement - mais que trop peut être perturbateur. « Vous ne devriez pas craindre le thrash », dit-il, « mais vous devez savoir quand il est utile et comment aider à atténuer ses inconvénients. L'un des meilleurs [moyens] d'atténuer les inconvénients du thrash est de commencer petit - avec tout .

Envisagez de commencer petit en mettant en place quelques éléments de base :

• Un système de contrôle de version pour stocker votre code. GitHub, GitLab et Bitbucket sont tous d'excellentes options ici. Assurez-vous que tous ceux qui utilisent le système peuvent accéder au code et proposer des modifications. Si possible, envisagez de rendre le code open source pour atteindre le public le plus large possible.
• Code CSS pour implémenter le système. Utilisez des variables Sass ou des propriétés personnalisées CSS pour stocker des "jetons de conception" - des valeurs courantes telles que les largeurs et les couleurs.
• Un fichier package.json qui définit comment les applications peuvent créer et installer le système de conception.
• Documentation HTML qui montre comment utiliser le système de conception, idéalement en utilisant le propre CSS du système.

La documentation node-sass du framework CSS Bulma décrit ces étapes un peu plus en détail. Vous pouvez ignorer l'installation et l'importation de Bulma si vous souhaitez repartir de zéro, ou vous pouvez l'inclure si vous souhaitez commencer avec certaines des bases en place.

Vous avez peut-être remarqué que je n'ai rien mentionné à propos de JavaScript ici. Vous voudrez peut-être ajouter cet élément éventuellement, mais vous n'en avez pas besoin pour commencer. Il est facile de descendre dans un terrier de lapin à la recherche des meilleurs et des plus récents outils JavaScript, et se perdre dans cette recherche peut rendre le démarrage plus difficile. Par exemple, « 5 raisons pour lesquelles les composants Web sont parfaits pour les systèmes de conception » et « Pourquoi je n'utilise pas de composants Web » présentent tous deux des arguments valables, mais vous seul pouvez décider quels outils conviennent à votre système. Commencer avec seulement CSS et HTML vous permet de recueillir des commentaires du monde réel qui vous aideront à prendre cette décision le moment venu.

Lorsque vous publiez de nouvelles versions du système, mettez à jour le numéro de version de votre système pour indiquer ce qui a changé. Utilisez la version sémantique pour indiquer ce qui a changé avec un nombre comme "1.4.0". Incrémentez le dernier chiffre pour les corrections de bogues, le chiffre du milieu pour les nouvelles fonctionnalités et le premier chiffre pour les modifications importantes et perturbatrices. Continuez à communiquer avec les personnes qui utilisent le système de conception, invitez des commentaires et des contributions, et apportez de petites améliorations au fur et à mesure. Cette méthode de travail collaborative et itérative peut aider à minimiser le « thrash » et à établir un sentiment de propriété partagée.

Enfin, envisagez de publier votre système de conception sous forme de package sur npm afin que les développeurs puissent l'utiliser en exécutant la commande npm install your-design-system . Par défaut, les packages npm sont publics, mais vous pouvez également publier un package privé, publier le package dans un registre privé ou demander aux développeurs d'installer le package directement à partir d'un système de contrôle de version. L'utilisation d'un référentiel de packages facilitera la découverte et l'installation des mises à jour, mais l'installation directe à partir du contrôle de version peut être une solution simple à court terme pour aider les équipes à démarrer.

Si vous souhaitez en savoir plus sur le côté ingénierie des choses, Construisez votre système de conception de Katie Sylor-Miller fournit une fantastique plongée en profondeur. (Divulgation complète : j'ai travaillé avec Katie.)

Emballer

Les systèmes de conception sont constitués de code, de conceptions et de documentation ainsi que de relations, de communication et de confiance mutuelle. En d'autres termes, ce sont des systèmes socio-techniques. Pour construire un système de conception, ne commencez pas par écrire du code et choisir des outils ; commencez par parler aux personnes qui utiliseront le système. Renseignez-vous sur leurs besoins et leurs contraintes et aidez-les à résoudre des problèmes. Lorsque vous prenez des décisions techniques, de conception ou de stratégie, considérez les besoins de ces personnes plutôt que la « meilleure » manière théorique de faire les choses. Commencez petit, itérez et communiquez au fur et à mesure. Gardez votre système aussi simple que possible pour minimiser le thrash, et invitez les commentaires et les contributions pour établir un sentiment de propriété partagée.

En accordant un poids égal aux considérations techniques et interpersonnelles, nous pouvons tirer parti des systèmes de conception tout en évitant les pièges. Nous pouvons travailler de manière efficace et humaine ; nous n'avons pas à choisir l'un plutôt que l'autre. Nous pouvons responsabiliser les équipes plutôt que de les limiter. Des équipes responsabilisées nous aident en fin de compte à mieux servir nos utilisateurs - ce qui, après tout, est la raison pour laquelle nous sommes ici en premier lieu.

Lectures complémentaires sur SmashingMag :

• Conseils pour la gestion des systèmes de conception
• Inclure l'animation dans votre système de conception
• Au-delà des outils : comment la création d'un système de conception peut améliorer votre façon de travailler
• Construire un système de conception à grande échelle pour le gouvernement américain (étude de cas)