Avant de dessiner une refonte, inventoriez les écrans existants et les états nécessaires au parcours. Une page vide, une erreur et une confirmation ne racontent pas la même chose. La maquette doit rendre ces différences explicites pour éviter que le développement les découvre trop tard.
Partir des tâches et des contraintes connues
Reprenez les problèmes relevés dans votre audit UX du site existant. Associez chaque écran à une tâche, puis notez les informations qui doivent rester accessibles. Un écran peut être visuellement daté tout en contenant une explication essentielle au lecteur.
Inventoriez également les contraintes : contenu disponible, données reçues, permissions, longueurs variables et règles de validation. Séparez ce qui est confirmé de ce qui reste à décider. Une hypothèse silencieuse dans une maquette peut devenir une règle involontaire dans le produit.
Organiser les écrans et leurs états
Préparez un espace par parcours, avec des noms compréhensibles. Dans Figma, les frames servent à structurer des zones de conception. Votre organisation doit surtout permettre à une autre personne de retrouver l'écran et son contexte.
Pour chaque écran, examinez les états pertinents : initial, contenu long, absence de résultat, chargement, erreur et confirmation. Ne créez pas une variante pour remplir une liste si elle n'a aucun sens dans le parcours. En revanche, documentez clairement un état indispensable qui ne dispose pas encore de son contenu final.
Exemple fictif : une page de réservation
Imaginons la refonte d'une réservation d'atelier. L'écran principal montre une date disponible et un bouton. Préparez aussi la date complète, l'absence de créneau, l'échec de récupération des disponibilités et la confirmation après choix.
Ajoutez une annotation pour chaque différence : texte attendu, action proposée et information conservée. Si la disponibilité ne peut pas être connue, la maquette ne doit pas afficher par défaut une place libre. Ce cas fictif décrit les décisions à préparer, pas une application testée.
Reliez ensuite les écrans dans l'ordre du parcours. Une confirmation doit avoir un point d'arrivée identifié et une suite compréhensible. Un écran isolé et soigné ne suffit pas si personne ne sait comment on y accède.
Préparer la vérification et la transmission
Associez les changements importants à un critère observable : retrouver une condition, comprendre une erreur ou revenir à l'étape précédente. Utilisez ces critères pour tester le prototype avant le développement.
Si l'environnement de conception reste à choisir, comparez les contraintes de l'équipe dans le guide Figma ou Penpot. Ne migrez pas tous les fichiers au milieu du projet sans essai représentatif et possibilité de retour.
Terminez avec une revue de livraison : écrans nommés, états documentés, questions ouvertes identifiées et contenus disponibles. La maquette prépare le code ; elle ne démontre ni la performance future ni l'accessibilité des composants développés.
Questions fréquentes
Faut-il reproduire toutes les pages de l'ancien site ?
Pas forcément. Représentez les modèles et les différences qui changent le comportement. Gardez un inventaire des pages pour vérifier qu'une particularité importante n'a pas été perdue dans le regroupement.
Peut-on commencer avec du faux texte ?
Pour explorer une disposition, oui. Avant validation, éprouvez-la avec des contenus réalistes et des longueurs difficiles. Un titre artificiellement court peut cacher un problème de structure.
Qui doit valider les états d'erreur ?
Les personnes qui connaissent le parcours et le traitement des données doivent participer à leur définition. La rédaction prépare les messages, tandis que le développement vérifie leur correspondance avec les échecs réels possibles.
Sources
Documentation consultée lors de la relecture du 10 septembre 2026.