Comment Progress utilise Figma pour gérer le processus de conception

Découvrez comment les équipes de conception et de développement de Progress collaborent avec Figma pour créer de nouveaux composants pour la bibliothèque d’interface utilisateur KendoReact.

Vous êtes-vous déjà demandé comment la magie se produit lorsqu’il s’agit de concevoir et de développer nos bibliothèques de composants Telerik et Kendo UI ? Comme beaucoup d’équipes, nous coordonnons étroitement nos équipes de conception et de développement, avec l’aide de Figma ! Jetons un coup d’œil au fonctionnement du processus de création de composants pour notre équipe KendoReact.

Identifier le problème

Le chef de produit (PM) est le premier à tenter de saisir le problème à résoudre. Ils sont chargés de synthétiser les commentaires, les tendances du secteur et les témoignages d’utilisateurs afin de trouver les endroits où le KendoRéagir La bibliothèque de composants peut être étendue ou améliorée.

Le processus de conception commence lorsqu’un PM remet à un concepteur une liste de suggestions de fonctionnalités qu’il a créées sur la base de cette recherche. Le concepteur peut alors poser des questions, valider et affiner le problème à résoudre à partir de ce point de départ.

Lorsque le PM et le concepteur sont d’accord sur le travail, le projet sera alors ajouté à la feuille de route. Lors de la prochaine réunion de planification, toutes les équipes (produit, conception et ingénierie) discuteront des délais raisonnables et du moment où cela pourrait s’intégrer dans le calendrier de sortie. L’équipe de conception travaille sur une version complète avant l’équipe d’ingénierie, ce qui nécessite donc de la coordination et beaucoup de planification !

Exploration

Une fois que le concepteur est affecté au composant, il peut commencer son travail sur la base de la rédaction qu’il a créée avec le PM. Ce concepteur unique sera responsable de ce composant tout au long du processus : il mènera le travail à bien, de l’idée à la mise en œuvre.

Le concepteur prendra ensuite le temps de faire sa propre exploration et recherche. Cela peut inclure un certain nombre de choses, notamment : parler aux utilisateurs, comparer les approches des concurrents, examiner les applications en contexte de ce composant et tirer parti des années d’expérience de leur équipe dans la conception de composants d’interface utilisateur. Lorsqu’ils sentent qu’ils ont une compréhension complète du problème que ce composant va résoudre, ainsi que quelques idées sur la façon de l’aborder, alors il est temps de commencer à créer !

Créer la solution

Le concepteur commence par créer des croquis libres pour travailler sur ses propres idées et déterminer quelle approche sera la plus efficace. Une fois qu’ils ont un assez bon plan et qu’ils sont prêts à commencer à le partager avec d’autres et à recevoir des commentaires, ils transformeront ces croquis en wireframes ou en simples maquettes dans Figma.

Puisque nous avons un Kit Figma pour chaque bibliothèque de composants qui fournit une répartition détaillée de tous nos composants de base, nos concepteurs peuvent gagner beaucoup de temps en exploitant ces ressources au lieu de créer entièrement chaque nouveau composant à partir de zéro. Cela signifie également qu’ils n’auront pas à réfléchir aux états d’interaction de chaque pièce atomique au sein d’un composant plus grand : les boutons, les menus déroulants, les cases à cocher, les entrées et bien plus encore ont déjà des états d’interaction bien définis et documentés dans les kits Figma qui peuvent être inclus. lors de la construction de nouveaux composants.

Partager la solution

Étant donné que les équipes de Kendo UI sont entièrement distantes, nous communiquons principalement les nouvelles conceptions de composants de manière asynchrone à l’aide des problèmes GitHub. Lorsque le concepteur est prêt à partager avec les équipes d’ingénierie et de produit, il crée un problème dans lequel il peut expliquer la solution suggérée. Cela inclut le fichier Figma ainsi que leur justification de conception. De cette façon, le concepteur guide l’équipe dans sa réflexion concernant ses choix et les fonctionnalités incluses, mais sans que tout le monde soit littéralement dans la même pièce en même temps.

Une fois celui-ci publié, les ingénieurs peuvent explorer et inspecter le fichier Figma, poser toutes les questions qu’ils pourraient avoir, ainsi qu’estimer le temps de construction et soulever toute préoccupation quant à la faisabilité. Le PM peut également poser des questions et finalement indiquer s’il pense que cette proposition résout de manière adéquate le problème qu’il a identifié au début du processus. Si la discussion devient compliquée ou s’il y a beaucoup de questions à répondre, des appels sont programmés selon les besoins pour régler les détails, mais, le plus souvent, les équipes peuvent obtenir tout ce dont elles ont besoin via la communication écrite. Une fois que tout le monde est d’accord, il est temps pour le designer de vraiment creuser !

Bâtiment

Une fois que le concepteur a reçu les commentaires dont il a besoin, il peut les utiliser et commencer à créer l’intégralité du composant. Même s’ils n’ont reçu comme par magie aucune suggestion ou critique, il reste encore plein de petits détails à peaufiner !

Une fois la conception complète et le prototype terminés, le concepteur doit ensuite versionner ce composant pour refléter toutes nos différentes options de thème : ce n’est pas une mince tâche ! Mais il est crucial de garantir que l’expérience utilisateur soit tout aussi efficace, quelle que soit la manière dont les couleurs ou le thème peuvent modifier l’apparence du composant. Nous avons appris par expérience qu’il ne faut pas aller trop loin dans un design et se rendre compte ensuite que cela ne fonctionnera tout simplement pas avec un thème spécifique.

Au fur et à mesure qu’ils travaillent, le concepteur publiera les mises à jour dans le même problème GitHub qu’il a ouvert auparavant. Cela leur permet de partager des mises à jour informatives, de poser des questions, d’obtenir davantage de commentaires, d’expliquer les modifications qu’ils ont dû apporter depuis la proposition ou d’ouvrir des discussions sur les fonctionnalités du composant.

Le plus important, cependant, est que l’ingénieur a été impliqué tout au long du processus, depuis la première proposition. Cela réduit considérablement les frictions lors du transfert, car l’ingénieur aura une compréhension beaucoup plus approfondie non seulement du problème d’origine, mais également des raisons pour lesquelles les différentes décisions de conception ont été prises. De plus, cela leur permet de signaler tout signal d’alarme ou toute préoccupation qu’ils ont quant à la faisabilité de la construction du composant suffisamment tôt dans le processus pour que son pivotement ne soit pas trop perturbateur. Ils peuvent toujours consulter le fichier Figma partagé pour voir la progression d’une conception et faire part de leurs commentaires.

Remettre

Une fois que tout est fait du côté de la conception et que tout le monde dans le fil de discussion GitHub a obtenu l’approbation, il est temps de passer la main à l’ingénierie. Les développeurs s’associent aux concepteurs au fur et à mesure qu’ils entrent dans cette phase afin qu’ils puissent continuer à poser des questions et à collaborer tout au long de ce processus. Ce n’est pas parce que les fichiers Figma sont terminés que le travail du concepteur est terminé !

Les spécificités du processus de transfert sont quelque chose que les individus jumelés gèrent eux-mêmes : le concepteur et le développeur sont habilités à travailler ensemble selon leurs besoins afin de régler les détails et de procéder aux ajustements nécessaires.

L’une des choses qui, selon nous, contribue grandement à ce succès est la distinction entre les ingénieurs « Front of the Front End » (FotFE) et les autres développeurs. Brad Frost a été le premier à inventer le terme « Front of the Front End », et c’est un terme incroyablement utile et précis : le front-end est devenu un espace très vaste, et l’ensemble des compétences nécessaires pour gérer les applications d’état et d’architecte peut être incroyablement différent. des compétences nécessaires pour écrire du HTML et du CSS beaux et accessibles.

Lorsque vous embauchez des spécialistes sur le FotFE, cela permet à ce développeur de prendre la tête des communications de transfert, car ils sont naturellement plus proches de l’aspect conception des choses. J’ai beaucoup parlé de l’importance de partager la même langue, et voici cela en action. Un autre avantage de ceci est la façon dont cela permet à nos développeurs FotFE de collaborer entre nos équipes en utilisant différents frameworks, car ces développeurs ne sont pas eux-mêmes spécialisés dans un framework. C’est le meilleur moyen que nous ayons trouvé pour garantir que nos composants se présentent et se comportent de la même manière, quel que soit le framework qui les alimente en coulisses.

Les ingénieurs FotFE peuvent utiliser les outils Figma inspect et Dev Mode pour créer l’interface utilisateur du nouveau composant sans avoir à deviner les valeurs, à demander au concepteur ou à spéculer sur les mises en page réactives : tout est déjà dans le fichier Figma. Bien sûr, s’il y a sont Pour toute question supplémentaire, le concepteur est là pour vous aider. Mais la plupart du temps, les détails sont déjà capturés dans Figma.

Mise à jour des kits Figma

La dernière étape du processus de l’interface utilisateur de Kendo consiste à revenir en arrière et à mettre à jour nos kits Figma publics avec les nouvelles conceptions de composants, afin que tous les concepteurs externes utilisant notre produit soient au courant des dernières et meilleures versions.

Nous alignons les kits Figma publics sur la version actuelle du composant, de sorte que le concepteur ait le temps de mettre à jour ces fichiers pendant que l’ingénieur construit le composant (et le temps pour le concepteur d’effectuer les mises à jour ou les ajustements nécessaires pour les rendre aussi clairs que possible). ). Les fichiers que nous ajoutons aux kits Figma publics proviennent directement des fichiers de conception à partir desquels nos composants sont construits. C’est une façon pour nous de « manger notre propre cuisine » et de tester les kits Figma. Après tout, quelle meilleure façon pour nous de nous assurer que les kits Figma sont utiles que de construire directement à partir d’eux nous-mêmes ?

Essayez-le vous-même

Si vous essayez d’établir un processus de conception, essayez de l’utiliser comme base, mais n’ayez pas peur de faire les ajustements dont vous avez besoin pour que cela fonctionne pour vous ! Le meilleur processus est celui que tout le monde utilise, donc si quelque chose s’avère être un problème, il n’est pas nécessaire de s’y accrocher. Voyez si vous pouvez résoudre pourquoi cela ne fonctionne pas ; Parfois, de petits ajustements peuvent être apportés pour que quelque chose fonctionne. Des outils comme Figma, Générateur de thèmes et les bibliothèques de composants Telerik et Kendo UI peuvent aider à accélérer le processus et à supprimer les obstacles. Nous le saurions : après tout, nous les utilisons aussi !