Une approche moderne du design (défis de développement) —

À propos de l'auteur

Mikołaj est un designer et développeur front-end qui dirige une équipe de conception chez ucreateune société britannique spécialisée dans la création de startups. Il est passionné par…

En savoir plus sur

Mikołaj
↬

Les frictions dans la coopération entre les concepteurs et les développeurs alimentent une discussion en constante évolution aussi ancienne que l'industrie elle-même. Nous avons parcouru un long chemin jusqu'où nous en sommes aujourd'hui. Nos outils ont changé. Nos processus et méthodologies ont changé. Mais les problèmes sous-jacents restaient souvent les mêmes.

L'un des problèmes récurrents que j'ai souvent tendance à voir, quels que soient le type et la taille de l'équipe, est le maintenir une source de vérité fiable. Même en embauchant les meilleures personnes et en utilisant des solutions éprouvées aux normes de l'industrie, nous avons souvent le dégoût que quelque chose aurait certainement pu être mieux fait. La tristement célèbre « version finale » est souvent répartie dans la documentation technique, les fichiers de conception, les feuilles de calcul et d'autres endroits. Les garder tous synchronisés est généralement une tâche fastidieuse et intimidante.

Remarque : Cet article a été écrit en collaboration avec l'équipe UXPin. Les exemples présentés dans cet article ont été créés dans l'application UXPin. Certaines fonctionnalités ne sont disponibles que sur les forfaits payants. L'aperçu complet de la tarification d'UXPin peut être trouvé ici.

Le problème avec les outils de conception

En parlant de maintenir une source de véritél'inefficacité des outils de conception est souvent indiqué comme l'un des points douloureux les plus douloureux. Les outils de conception modernes évoluent et ils évoluent rapidement avec d'énormes efforts. Mais lorsqu'il s'agit de jeter un pont entre la conception et le développement, il n'est pas rare d'avoir l'impression que bon nombre de ces efforts sont basés sur des hypothèses erronées.

La plupart des outils de conception modernes sont basés sur des modèles différents des technologies utilisées pour mettre en œuvre les conceptions plus tard. Ils sont construits comme des éditeurs graphiques et se comportent comme tels. La façon dont les mises en page sont construites et traitées dans les outils de conception est finalement différente de tout ce que CSS, JavaScript et d'autres langages de programmation ont à offrir. Construire des interfaces utilisateur à l'aide de graphiques vectoriels (ou même raster) est une hypothèse constante de comment et si ce que vous créez doit être transformé en code plus tard.

Les concepteurs finissent souvent par se lamenter sur leur les créations ne sont pas mises en œuvre comme prévu. Même les efforts les plus courageux vers des conceptions au pixel près ne résolvent pas tous les problèmes. Dans les outils de conception, il est presque impossible d'imaginer et de couvrir tous les cas possibles. La prise en charge de différents états, la modification de la copie, différentes tailles de fenêtres, résolutions d'écran, etc., fournissent simplement trop de variables changeantes pour les couvrir toutes.

En plus de cela, certaines contraintes et limitations techniques. Étant un concepteur sans expérience de développement préalable, il est extrêmement difficile de prendre en compte tous les facteurs techniques. Rappelez-vous tous les états possibles des entrées. Comprenez les limites de la prise en charge du navigateur. Prévoyez les implications de votre travail sur les performances. Concevoir pour l'accessibilité, au moins dans un sens beaucoup plus large que le contraste des couleurs et les tailles de police. Conscients de ces défis, nous acceptons certaines conjectures comme un mal nécessaire.

Mais les développeurs doivent aussi souvent dépendre de conjectures. Les interfaces utilisateur simulées avec des éditeurs graphiques répondent rarement à toutes leurs questions. Est-ce le même composant que celui que nous avons déjà, ou non ? Dois-je le traiter comme un état différent ou comme une entité distincte ? Comment cette conception doit-elle se comporter lorsque X, Y ou Z ? Pouvons-nous le faire un peu différemment car ce serait plus rapide et moins cher ? Ironiquement, demander à la personne qui a créé les designs en premier lieu n'est pas toujours utile. Pas rarement, ils ne le savent pas non plus.

Et généralement, ce n'est pas là que s'arrête la portée de la frustration croissante. Parce qu'alors, il y a aussi tout le monde . Managers, intervenants, chefs d'équipe, vendeurs. Avec leur attention et leur capacité mentale étirées parmi tous les outils et les endroits où vivent les différentes parties du produit, ils ont plus de mal que quiconque à en avoir une bonne compréhension.

Naviguer dans les prototypes, comprendre pourquoi certaines fonctionnalités et certains états sont manquants. des conceptions, et faire la distinction entre ce qui manque, ce qui est un travail en cours et ce qui a été consciemment exclu de la portée semble presque impossible. Itérer rapidement sur ce qui a déjà été fait, visualiser vos commentaires et présenter vos propres idées semble également difficilement possible. Ironiquement, des outils et des processus de plus en plus sophistiqués sont destinés aux concepteurs et aux développeurs pour mieux travailler ensemble ; ils placent la barre encore plus haut et la participation active aux processus pour d'autres personnes encore plus difficile.

Les solutions

D'innombrables chefs de notre industrie ont travaillé pour résoudre ces problèmes, ce qui a abouti à de nouveaux paradigmes, outils et concepts. Et en effet, beaucoup de choses ont changé pour le mieux. Jetons un coup d'œil rapide et quelles sont certaines des approches les plus courantes face aux défis décrits.

Concepteurs de codage

« Les concepteurs devraient-ils coder ? » est une question cliché discutée un nombre incalculable de fois à travers des articles, des conférences et tous les autres médias avec de nouvelles voix dans la discussion qui apparaissent avec une régularité stable de temps en temps. Il existe une hypothèse commune selon laquelle si les concepteurs «savaient comment coder» (ne commençons même pas à nous attarder sur la définition de «savoir coder» en premier lieu), il leur serait plus facile de concevoir des conceptions qui prennent en compte les contraintes technologiques et sont plus faciles à mettre en œuvre.

Certains iraient plus loin et diraient qu'ils devraient jouer un rôle actif dans la mise en œuvre. À ce stade, il est facile de conclure qu'il ne serait pas insensé d'ignorer complètement les outils de conception et de simplement "concevoir dans le code".

Aussi tentante que l'idée puisse paraître, elle fait rarement ses preuves dans la réalité. Tous les meilleurs concepteurs de code que je connais utilisent encore des outils de conception. Et ce n'est certainement pas dû à un manque de compétences techniques. Expliquer le pourquoi est important de mettre en évidence une différence entre l'idéation, l'esquisse et la construction de la chose réelle.

Tant qu'il existe de nombreux cas d'utilisation valides pour la « conception en code »telles que l'utilisation de styles et de composants prédéfinis pour créer rapidement une interface entièrement fonctionnelle sans vous soucier du tout des outils de conception, la promesse d'une liberté visuelle illimitée est offerte par les outils de conception toujours d'une valeur indéniable. De nombreuses personnes trouvent qu'esquisser de nouvelles idées dans un format offert par les outils de conception est plus facile et mieux adapté à la nature d'un processus créatif. Et cela ne va pas changer de sitôt. Les outils de conception sont là pour rester et pour de bon.

Systèmes de conception

La grande mission des systèmes de conceptionl'un des plus grands mots à la mode du monde de la conception numérique ces dernières années, a toujours était exactement cela : limiter les conjectures et les répétitions, améliorer l'efficacité et la maintenabilité, et unifier les sources de vérité. Les systèmes d'entreprise tels que Fluent ou Material Design ont fait beaucoup de travail de plaidoyer pour l'idée et ont donné un élan à l'adoption du concept par les grands et les petits acteurs. Et en effet, les systèmes de conception ont contribué à changer beaucoup pour le mieux. Une approche plus structurée du développement d'une collection définie de principes de conception, de modèles et de composants a aidé d'innombrables entreprises à construire des produits meilleurs et plus faciles à entretenir.

Certains défis n'avaient cependant pas été résolus immédiatement. Concevoir des systèmes de conception dans des outils de conception populaires a entravé les efforts de beaucoup pour parvenir à une source unique de vérité. Au lieu de cela, une pléthore de systèmes a été créée qui, même s'ils sont unifiés, existent toujours dans deux sources distinctes et incompatibles : une source de conception et une source de développement. Maintenir la parité mutuelle entre les deux s'avère généralement être une corvée pénible, répétant tous les points douloureux les plus détestés que les systèmes de conception essayaient de résoudre en premier lieu.

Design And Code Integrations

Pour résoudre les problèmes de maintenabilité de la conception systèmes, une autre vague de solutions est bientôt arrivée. Des concepts tels que les jetons de conception ont commencé à gagner du terrain. Certains étaient destinés à synchroniser l'état du code avec les conceptions, comme les API ouvertes qui permettent de récupérer certaines valeurs directement à partir des fichiers de conception. D'autres étaient destinés à synchroniser les conceptions avec le code, par ex. en générant des composants dans les outils de conception à partir du code.

Peu de ces idées ont été largement adoptées. Ceci est très probablement dû à l'avantage discutable des bénéfices possibles sur les coûts d'entrée nécessaires de solutions encore très imparfaites. La traduction automatique des conceptions en code pose toujours d'immenses défis pour la plupart des cas d'utilisation professionnels. Les solutions vous permettant de fusionner du code existant avec des conceptions ont également été sévèrement limitées.

Par exemple, aucune des solutions vous permettant d'importer des composants codés dans des outils de conception, même visuellement fidèles à la source, ne reproduirait entièrement le comportement de tels Composants. Aucun jusqu'à présent.

Fusionner la conception et le code avec UXPin

UXPin, étant une application de conception mature et complète, n'est pas un nouvel acteur sur la scène des outils de conception. Mais ses récents progrès, tels que la Merge technologysont ce qui peut changer la façon dont nous pensons aux outils de conception et de développement.

UXPin avec la technologie Merge nous permet d'intégrer des composants réels et vivants dans la conception en en préservant à la fois leurs visuels et leurs fonctionnalités, le tout sans écrire une seule ligne de code. Les composants, même s'ils sont intégrés dans des fichiers de conception, doivent se comporter exactement comme leurs équivalents réels &mdah; car ils sont leurs véritables homologues. Cela nous permet non seulement d'obtenir une parité transparente entre le code et la conception mais également de maintenir les deux en synchronisation ininterrompue.

UXPin prend en charge les bibliothèques de conception de composants React stockés dans les référentiels git ainsi qu'un intégration robuste avec Storybook qui permet l'utilisation de composants de presque n'importe quel framework frontal populaire. Si vous souhaitez essayer vous-même, vous pouvez en demander l'accès sur le site Web UXPin :

La fusion de composants en direct avec des conceptions dans UXPin prend étonnamment peu d'étapes. Après avoir trouvé le bon composant, vous pouvez le placer sur le canevas de conception en un clic. Il se comportera comme n'importe quel autre objet dans vos conceptions. Ce qui le rendra spécial, c'est que, même s'il fait partie intégrante des conceptions, vous pouvez désormais l'utiliser et le personnaliser de la même manière que vous le feriez dans le code .

UXPin vous donne accès aux propriétés du composant. , vous permet de modifier ses valeurs et ses variables et de le remplir avec vos propres données. Une fois le prototype démarré, le composant doit se comporter exactement comme prévu, en conservant tous les comportements et interactions.

Dans vos conceptions, vous pouvez mélanger et assortir un nombre illimité nombre de bibliothèques et de systèmes de conception . En plus d'ajouter votre propre bibliothèque, vous pouvez également choisir parmi une grande variété de bibliothèques open source disponibles telles que Material Design, Fluent UI ou Carbon.

L'utilisation d'un composant « tel quel » signifie également qu'il doit se comporter en fonction du changement de contexte, comme la largeur de la fenêtre. En d'autres termes, ces composants sont entièrement réactifs et adaptables.

Remarque : Si vous souhaitez en savoir plus sur la création de conceptions vraiment réactives avec UXPin, je vous encourage fortement à consulter cet article.

Le contexte peut aussi signifier la thématisation. Quiconque a essayé de construire (et de maintenir !) un système de conception thématique dans un outil de conception, ou au moins de créer un système qui vous permet de basculer facilement entre un thème clair et un thème sombre, sait à quel point c'est une tâche délicate et à quel point le les résultats le sont généralement. Aucun des outils de conception n'est bien optimisé pour le thème prêt à l'emploi et les plugins disponibles visant à résoudre ce problème sont loin de le résoudre complètement. en tant que composants réels et vivants. Non seulement vous pouvez créer autant de thèmes que vous le souhaitez, mais les changer peut être aussi rapide que de choisir le bon thème dans une liste déroulante. (Vous pouvez en savoir plus sur le changement de thème avec UXPin ici.)

Avantages

UXPin avec la technologie Merge permet un niveau de parité entre la conception et le code rarement vu auparavant. Être fidèle à la source dans un processus de conception apporte des avantages irréprochables pour tous les aspects du processus. Les concepteurs peuvent concevoir en toute confiance en sachant que ce qu'ils font ne sera pas mal interprété ou mal développé. Les développeurs n'ont pas à traduire les conceptions en code et à s'embrouiller dans des cas extrêmes inexplicables et des scénarios découverts. En plus de cela, tout le monde peut participer au travail et prototyper rapidement ses idées en utilisant des composants actifs sans aucune connaissance du code sous-jacent. Atteindre des processus plus démocratiques et participatifs est beaucoup plus à portée de main.

Fusionner votre conception avec le code pourrait non seulement améliorer la façon dont les concepteurs coopèrent avec les autres constituants de l'équipe, mais aussi affiner leurs processus et pratiques internes. UXPin avec la technologie Merge peut changer la donne pour ceux qui se concentrent sur l'optimisation des efforts de conception à grande échelleparfois appelée DesignOps.

Utiliser la bonne source de vérité permet inexplicablement plus facile de maintenir la cohérence entre les travaux produits par différentes personnes au sein de l'équipe, aide à les maintenir alignés et résout les bons problèmes avec un ensemble commun d'outils. Fini les « symboles détachés » avec une poignée de variations non sollicitées.

En fin de compte, ce que nous obtenons, ce sont d'énormes gains de temps. Les concepteurs gagnent du temps en utilisant les composants en toute confiance et leurs fonctionnalités hors de la boîte. Ils n'ont pas besoin de mettre à jour les fichiers de conception au fur et à mesure que les composants changent, ni de documenter leur travail et de « faire signe de la main » pour expliquer leurs visions au reste de l'équipe. Les développeurs gagnent du temps en obtenant les composants des concepteurs d'une manière instantanément digeste qui ne nécessite pas de conjectures ni de bricolage supplémentaire.

Les personnes responsables des tests et de l'assurance qualité gagnent du temps en recherchant les incohérences entre les conceptions et le code et en déterminant si l'implantation s'est déroulée comme prévu . Les parties prenantes et les autres membres de l'équipe gagnent du temps grâce à une gestion plus efficace et une navigation plus facile de ces équipes. Moins de frictions et des processus transparents limitent la frustration parmi les membres de l'équipe.

Inconvénients

Bénéficier de ces avantages entraîne cependant certains coûts d'entrée. Pour utiliser efficacement des outils tels que UXPin dans votre processus, vous devez disposer d'un système de conception existant ou d'une bibliothèque de composants en place. Alternativement, vous pouvez baser votre travail sur l'un des systèmes open source qui fournirait toujours un certain niveau de limitation.

Cependant, si vous vous engagez à créer un système de conception en premier lieu, utilisez UXPin avec la technologie Merge dans votre processus viendrait à peu ou pas de frais supplémentaires. Avec un système de conception bien construit, l'adoption d'UXPin ne devrait pas être une lutte, tandis que les avantages d'un tel changement pourraient s'avérer considérablement. . Actuellement, nous pouvons observer un glissement vers des processus plus unifiés qui transforment non seulement le médium mais aussi la façon dont nous le créons. L'utilisation des bons outils est cruciale pour ce changement. UXPin avec la technologie Merge est un outil de conception qui permet de combiner la conception avec des composants de code en direct et réduit considérablement l'écart entre les domaines de conception et de développement.

Where Next ?

(vf, il)