Aller au contenu
kenjtecJournal
Rechercher dans le Journal

Figma ouvre Code Layers : les idées interactives se retrouvent ensemble sur le canevas de conception

Les prototypes interactifs répondent à d’autres questions que les écrans attrayants. Une comparaison de dialogues montre comment Code Layers peut rendre visibles les décisions relatives au comportement.

Sur un petit prototype en carton, Ana ouvre un rabat comme une boîte de dialogue ; à côté se trouve un croquis de page avec les mêmes cartes. Illustration réalisée par IA.

Deux pages de rendez-vous ont l’air soignées. Toutes deux comportent un champ de date et un bouton Enregistrer. Sur la première, une boîte de dialogue modifie le rendez-vous ; sur la deuxième, une page distincte s’ouvre. Quelle version est la meilleure ? Une capture d’écran aide pour les couleurs et les espacements. Elle ne montre que de manière limitée si les personnes comprennent le déroulement.

Le 15 octobre 2026, Figma a ouvert Code Layers en version bêta. Les prototypes pris en charge peuvent être développés davantage avec du code et comparés sur le canevas de conception partagé ; du code existant peut être intégré dans les conditions documentées. D’un point de vue éditorial, l’aspect intéressant est le travail commun sur le comportement. Un prototype devient ainsi l’objet d’une décision au lieu de simplement montrer son résultat attrayant.

D’abord la même tâche, ensuite des interfaces différentes

Notre propre exemple est un événement associatif. La personne doit modifier la date, lire la condition de participation, puis enregistrer ou annuler. Les deux versions reçoivent le même titre, la même date et la même note plus longue. Si l’une des versions n’affichait qu’un court titre provisoire, la comparaison serait déjà faussée.

La boîte de dialogue conserve la vue d’ensemble des rendez-vous en arrière-plan. Une page de modification distincte offre plus d’espace. Ce sont des décisions de conception différentes, et non des jugements de qualité. Cela devient intéressant au niveau des transitions : où se trouve la personne après l’enregistrement ? Qu’advient-il de la saisie commencée lorsqu’elle annule ? Quelles informations restent visibles pendant la modification ?

Un modèle d’états permet de discuter du comportement

Décrivez d’abord le déroulement sans syntaxe de programmation. Le rendez-vous est visible. Modifier ouvre une saisie. Une saisie invalide entraîne une explication, et les entrées valides sont conservées. Enregistrer affiche l’état confirmé. Annuler ramène à l’état inchangé. Ce sont des exigences pour notre exemple, et non une promesse concernant des fonctionnalités intégrées de Figma.

View → Edit → Input
Input → valid → Save → Confirmation
Input → invalid → Hint + input kept
Input → Cancel → original view

Avec ce petit modèle, chaque version peut être examinée de manière ciblée. Peut-être la boîte de dialogue a-t-elle une excellente apparence, mais perd-elle le texte d’aide lorsqu’une erreur survient. Peut-être la page distincte est-elle moins élégante, mais rend-elle le chemin du retour plus facile à comprendre. L’évaluation porte alors sur un comportement observable, et non sur une préférence générale pour les boîtes de dialogue.

Les retours ont besoin d’un point de référence commun

Un commentaire utile serait : « Après avoir annulé, je ne savais pas si ma nouvelle date avait été enregistrée. » Il nomme l’endroit, l’action et l’incertitude. « Ça ne fait pas assez moderne », en revanche, ne fournit pas encore de question sur laquelle on puisse travailler. Lorsque les ébauches et les commentaires se trouvent sur le même canevas, le lien avec la version examinée peut être préservé.

Pour chaque modification, notez quelle incertitude elle est censée lever. Modifiez par exemple d’abord la confirmation, plutôt que de changer en même temps la police, les couleurs et la navigation. Il est ainsi plus facile de comprendre pourquoi une deuxième version produit une impression différente. Il ne s’agit pas d’une étude d’utilisabilité contrôlée, mais d’une discipline de travail judicieuse pour la phase de conception.

La décision est transférable ; le code ne l’est pas automatiquement

À la fin, il devrait y avoir une courte note de transmission : la version privilégiée, la tâche qu’elle prend en charge, les états pertinents et les questions en suspens. Une ébauche interactive avec des données d’exemple n’est pas encore une véritable plateforme de réservation. La connexion, les données enregistrées et les autorisations réelles doivent fonctionner séparément dans une application.

Pour un petit ajout côté client à une page KENJTEC, la décision peut ensuite être mise en œuvre avec vos propres HTML, CSS et JavaScript. Le KENJTEC WebSiteBuilder ai propose pour cela un mode développeur, avec un aperçu isolé et sa propre étape de publication du code. Vous transférez vous-même le composant concerné ; cela ne signifie ni une importation depuis Figma ni un hébergement pour n’importe quelle application de votre choix.

Selon l’état documenté, Code Layers reste une version bêta. La disponibilité, les projets de départ pris en charge et les conditions devraient être vérifiés à nouveau avant tout guide pratique concret. La méthode reste toutefois valable indépendamment de l’outil : ne comparez pas simplement deux écrans attrayants. Comparez deux réponses traçables à la même question sur la manière dont quelque chose est utilisé.

Sources et état

Recherches et documentation à la date du 25 octobre 2026. Concevoir ensemble avec des code layers sur le canevas.

Hambourg est notre point de départ.

L’utile vous accompagne.

L’IA en pratique depuis Hambourg, expliquée pour tous.

Articles enregistrés