Guide pratique
Livrer une interface UI que le développeur peut reprendre
Livrer une interface UI consiste à transmettre une version que le développeur peut comprendre et reprendre. Identifiez les écrans, leurs états, les règles et les ressources, puis contrôlez les accès au projet.
Définissez le périmètre de livraison, figez une version repérable et documentez les écrans, composants et états nécessaires. Donnez au développeur les accès convenus et au client une synthèse compréhensible. Gardez la distinction entre le fichier de conception vivant, les ressources exportées et le dossier livré à une date donnée.
Livrer une interface UI : définir ce qui doit être construit
Commencez par une liste des parcours couverts : inscription, tableau de bord, paiement, espace personnel. Pour chaque parcours, indiquez les écrans livrés et les situations encore hors périmètre. Une maquette d’accueil approuvée ne prouve pas que les erreurs de formulaire ou le menu mobile ont aussi été validés.
Préparez les états nécessaires à la tâche : chargement, absence de contenu, erreur, succès et contenu trop long. Utilisez des libellés réalistes. Une interface peut paraître finie avec des données idéales et devenir inutilisable dès qu’un nom déborde ou qu’une image manque.
Identifier la version remise au développeur
Nommez la version avec une date, un périmètre et un résumé des changements. Évitez de déplacer silencieusement les éléments validés pendant que le développement commence. L’historique de Figma permet notamment de retrouver des itérations ; la manière de les partager dépend de la configuration et des accès du fichier.
Ajoutez un tableau des changements après livraison : élément, ancienne règle, nouvelle règle et impact attendu. Une modification de couleur n’a pas le même effet qu’un parcours de connexion entièrement revu. Faites confirmer les changements qui modifient le travail ou le calendrier convenu.
Livrer les règles avec les ressources
Pour les composants réutilisables, indiquez leurs variantes, leurs états et les usages prévus. Associez les ressources à une destination : icônes de navigation, illustrations d’accueil, images de remplacement. Expliquez quelles images sont temporaires et lesquelles sont utilisables en production, avec leurs autorisations.
La documentation doit aussi décrire le comportement que l’image ne montre pas : ouverture d’un panneau, ordre des étapes, message après une action, retour au clavier. Rapprochez les ressources et les règles au lieu de multiplier les annexes que personne ne sait rattacher à un écran.
Vérifier les accès et organiser les questions
Testez l’accès depuis le rôle réellement attribué au destinataire. La documentation Figma distingue le partage, les autorisations et les liens vers les fichiers ou prototypes. Une invitation envoyée ne suffit donc pas à conclure que le développeur voit tous les éléments dont il a besoin.
Prévoyez un interlocuteur et un endroit unique pour les questions liées à la livraison. Un dossier DesignLockr peut réunir les exports de référence, l’inventaire et les autorisations utiles. Gardez l’outil de conception pour les fonctions de conception et vérifiez l’acceptation des fichiers avant de les ajouter.
EXEMPLE FICTIF
Exemple fictif : une réservation de cours
Un studio livre une interface à un développeur indépendant. La première version ne montrait que des cours disponibles.
- Le studio ajoute les écrans complet, annulé et sans résultat, avec leurs textes.
- Il identifie une livraison UI-03 et liste les composants remis.
- Le développeur signale une ambiguïté sur l’annulation ; la réponse est ajoutée aux règles de cette livraison.
La discussion porte sur un comportement précis et une version connue, sans réinterpréter toute la maquette.
Votre checklist avant de continuer
- Parcours inclus et exclus listés.
- États vides, erreurs et chargements décrits.
- Version de livraison identifiable.
- Ressources finales séparées des exemples temporaires.
- Licences et accès contrôlés.
- Questions et changements rattachés à la livraison.
Les questions à clarifier
Faut-il exporter chaque écran en image ?
Les images peuvent servir de référence de lecture, mais elles ne remplacent pas les règles de comportement ni les accès convenus au fichier de conception.
Le client et le développeur doivent-ils recevoir le même dossier ?
Ils peuvent partager une référence commune tout en recevant des explications différentes : parcours et décisions pour le client, règles et ressources pour le développeur.
Une maquette validée peut-elle encore évoluer ?
Oui. Identifiez la nouvelle version, décrivez le changement et clarifiez ses conséquences avant de remplacer la référence de travail.
Sources et repères
Avant le prochain envoi, gardez une référence claire.
Rassemblez les bons fichiers et la bonne version. Préparez ensuite un partage et les usages convenus.
Un handoff UI qui distingue le prototype des fichiers transmis
L’interface fictive Rivage possède cinq écrans, une bibliothèque de composants et un prototype de navigation. Le prototype permet de comprendre les transitions, mais il ne constitue pas l’inventaire des exports remis à l’intégrateur. Une icône manquante peut rester invisible pendant la démonstration et bloquer ensuite l’intégration d’un écran.
Listez les écrans, leurs états et les composants nécessaires. Rattachez les exports à une version de l’interface et recensez les polices, images et icônes avec leur provenance. Testez le lot de remise indépendamment du prototype. La checklist proposée conserve une ligne ouverte pour les ressources absentes plutôt que de considérer le handoff terminé parce que le lien de démonstration fonctionne.
Dans la grille, « RIV-UI-V3 » renvoie à « Cinq écrans de référence » ; son contrôle est « États retenus identifiés ». La ligne « RIV-COMP-V3 » concerne « Boutons et formulaires ». Gardez ces repères distincts dans votre exemplaire pour que le prochain échange puisse citer la bonne pièce et le point restant à examiner.
| Repère | Exemple fictif | Contrôle à effectuer |
|---|---|---|
| RIV-UI-V3 | Cinq écrans de référence | États retenus identifiés |
| RIV-COMP-V3 | Boutons et formulaires | Dépendances recensées |
| RIV-ICN-01 | Icône de recherche | Fichier présent à vérifier |
| RIV-PROT-V3 | Parcours interactif | Démonstration distincte de la remise |
Avant de poursuivre
- Inventorier les fichiers au-delà du lien de prototype.
- Vérifier les états et ressources manquants.
- Conserver les conditions des éléments tiers.
Exemple fictif — Un handoff UI qui distingue le prototype des fichiers transmis
Pour préparer la suite
Garder une trace de validation du livrable