Wireframer une app dans Figma quand t'as juste une idée floue, c'est l'enfer. Tu passes deux heures à chercher des composants, tu oublies l'écran d'erreur 404, et au final t'as un joli rendu vide de sens. Claude résout l'autre moitié du problème : la logique des écrans, la hiérarchie de l'info, les états. Pas le pixel. Cet article te donne la méthode en 5 prompts que j'utilise pour passer d'un brief flou à un set de wireframes exploitables en 90 minutes, illustrée sur une app fil rouge de suivi de factures pour freelances. Si tu débarques sur Claude, jette d'abord un œil au guide complet pour apprendre Claude en 2026, ça te donnera le contexte des modèles et des Projects qu'on va utiliser ici.
Pourquoi wireframer avec Claude plutôt que directement dans Figma
Claude ne dessine pas. Il ne sortira jamais un écran propre avec des composants Material. Mais il fait mieux qu'un humain seul sur trois choses : énumérer exhaustivement les écrans (y compris ceux qu'on oublie), structurer la hiérarchie d'information, et lister les états (vide, chargement, erreur, succès). Le wireframe sort en texte structuré ou en ASCII, et tu le transfères ensuite dans Figma, Penpot, ou tu le colles dans v0.dev pour générer un rendu visuel en quelques minutes.
Le gain de temps réel : 90 minutes pour 8 à 12 écrans avec états, contre une journée complète à manipuler des frames. Le périmètre où ça marche bien : app web ou mobile en mode MVP, avec un design system pas encore défini. Au-delà (système de design complexe, animations avancées, layouts en grille très denses), tu reviens sur un outil visuel.
Ce qu'il faut préparer avant de prompter
Sans input précis, Claude sort du wireframe générique qui ressemble à n'importe quel SaaS B2B. La préparation pèse 80% du résultat. Avant d'ouvrir une conversation, rassemble :
- Une phrase qui décrit l'app, verbe d'action inclus.
- Le persona principal, en une ligne (rôle, contexte, frustration actuelle).
- Le job-to-be-done, formulé du point de vue de l'utilisateur.
- 3 à 5 fonctionnalités prioritaires, hiérarchisées.
- Les contraintes techniques : mobile-first ou desktop-first, mode sombre, niveau d'accessibilité visé.
Notre fil rouge pour l'article : Factura, une app mobile-first de suivi de factures pour freelances solo. Persona : freelance créatif qui facture 5 à 15 clients par mois et oublie de relancer. JTBD : voir d'un coup d'œil ce qui est en retard de paiement et envoyer une relance en 2 taps. Fonctionnalités prioritaires : liste des factures, détail facture, créer une facture, relancer un client, dashboard des montants dus.
Prompt 1 : extraire la liste des écrans depuis le brief
Premier prompt, premier livrable : la liste exhaustive des écrans, y compris les secondaires que les débutants oublient (onboarding, vide, 404, modale de confirmation).
Rôle : tu es product designer senior, spécialisé apps mobiles B2B.
Contexte : je conçois Factura, app mobile-first de suivi de factures pour freelances.
Persona : freelance créatif, 5 à 15 factures par mois, oublie les relances.
JTBD : voir les retards de paiement et relancer en 2 taps.
Fonctionnalités prioritaires : liste factures, détail facture, création, relance client, dashboard.
Mission : liste tous les écrans nécessaires pour un MVP utilisable.
Inclus explicitement : auth, onboarding, états vides, écrans d'erreur, modales de confirmation, paramètres.
Format : tableau markdown avec colonnes Écran | Type (principal/secondaire) | Rôle utilisateur.Sur Factura, Claude sort en général 14 à 18 écrans là où on en avait listé 5. C'est exactement ce qu'on veut : la liste exhaustive, pas la liste idéale. Tu coupes après, pas avant.
Prompt 2 : définir la hiérarchie d'information par écran
Maintenant qu'on a la liste, on attaque écran par écran. La consigne clé : une seule action primaire par écran. Si Claude en propose deux, tu lui demandes de choisir.
Pour chaque écran de la liste précédente, structure le contenu en zones :
- Header (titre, navigation, actions globales)
- Contenu principal (le cœur de l'écran)
- Actions secondaires (boutons, liens annexes)
- Footer ou tab bar si pertinent
Contrainte : une seule action primaire par écran, identifiée en gras.
Format : YAML, un bloc par écran.Extrait de sortie pour le dashboard de Factura :
ecran: dashboard
header:
titre: "Bonjour {prénom}"
actions_globales: [icone_notifications, avatar_profil]
contenu_principal:
- bloc_synthese: montant_du_total, nb_factures_retard
- liste_factures_recentes: 3 derniers items
actions_secondaires:
- lien: "Voir toutes les factures"
footer:
tab_bar: [accueil, factures, creer, clients, reglages]
action_primaire: "**Bouton + flottant : Créer une facture**"Le YAML est volontaire : c'est réutilisable, ça se parse, et ça force Claude à être structuré. Le markdown libre donne du flou.
Prompt 3 : générer le wireframe ASCII de chaque écran
L'ASCII marche bien parce que Claude le rend proprement, ça se copie n'importe où (Notion, Slack, README), et ça force la simplicité. Pas de tentation de détailler des ombres ou des coins arrondis.
Prends la hiérarchie YAML de l'écran [dashboard] et génère un wireframe ASCII.
Utilise des boîtes simples, des labels courts, des [placeholders] pour le contenu dynamique.
Largeur cible : 40 caractères (mobile portrait).Exemple de sortie sur le dashboard :
+--------------------------------------+
| Bonjour Sarah 🔔 (avatar) |
+--------------------------------------+
| |
| À encaisser |
| ┌──────────────────────────────┐ |
| │ 4 320 € 3 en retard │ |
| └──────────────────────────────┘ |
| |
| Dernières factures |
| ┌──────────────────────────────┐ |
| │ Client A 1 200 € J+15 │ |
| │ Client B 800 € payée │ |
| │ Client C 2 320 € J-3 │ |
| └──────────────────────────────┘ |
| → Voir toutes les factures |
| |
| ( + ) |
+--------------------------------------+
| 🏠 📄 ➕ 👤 ⚙ |
+--------------------------------------+Limite à connaître : pour des layouts complexes en grille (genre tableau avec 8 colonnes ou kanban à 5 colonnes), l'ASCII tasse tout et devient illisible. Dans ce cas, demande une description textuelle détaillée à la place, écran par écran, zone par zone, avec dimensions relatives.
Prompt 4 : ajouter les états et les interactions
C'est ce qui sépare un wireframe joli d'un wireframe utilisable par un dev. Sans les états, le développeur va inventer des comportements et ça partira en review-ping-pong.
Pour chaque écran principal (dashboard, liste factures, détail facture, création), liste :
1. État vide (premier usage, aucune donnée)
2. État chargement (skeleton ou spinner ?)
3. État erreur (réseau, validation, serveur)
4. État succès (après action primaire)
5. Micro-interactions (tap, swipe, long-press, pull-to-refresh)
Pour chaque état, donne : déclencheur, contenu affiché, action de sortie.Sur Factura, Claude m'a sorti des états auxquels je n'avais pas pensé : l'état "facture envoyée mais non lue" (différent de "en attente de paiement"), le swipe-pour-relancer sur la liste, le pull-to-refresh qui resynchronise les paiements Stripe. C'est rarement révolutionnaire, c'est souvent évident une fois listé, mais c'est ce qui rend le wireframe complet.
Prompt 5 : exporter vers un outil visuel
Dernier prompt : transformer tout ça en brief structuré que tu peux coller dans v0.dev, Lovable, Penpot ou envoyer à un designer humain.
Génère un brief de wireframe par écran, format markdown, structure suivante :
## [Nom écran]
- Layout : (mobile portrait, desktop, etc.)
- Composants : liste exhaustive avec dimensions relatives
- Contenu : textes exacts, placeholders réalistes
- Actions : primaire (bouton, taille, position), secondaires
- États : référence aux états du prompt précédent
Cible : ce brief doit être directement utilisable dans v0.dev pour générer un rendu React + Tailwind.Tu copies le brief écran par écran dans v0 ou Lovable, et tu obtiens un rendu visuel en 2 minutes par écran. Pour Figma, ce même brief sert de spec à un designer qui dessine plus vite parce qu'il n'a plus à inventer la structure. Si t'es plutôt sur de l'app web avec du code derrière, regarde aussi comment créer un site web avec Claude du brief au déploiement, le workflow est cousin.
Les pièges à éviter avec cette méthode
Piège 1 : prompter sans persona clair. Tu obtiens un dashboard de SaaS générique avec les mêmes KPIs que tout le monde. Correction : prends 10 minutes à écrire le persona avant le prompt 1, pas après.
Piège 2 : tout faire en un seul prompt géant. Au-delà de 3 écrans détaillés, Claude perd le fil, oublie des zones, mélange les conventions. La méthode en 5 prompts existe précisément pour ça : un prompt = un livrable atomique. Tu peux relancer le prompt 3 sur un seul écran si le rendu est moyen, sans casser le reste.
Piège 3 : sauter les états. Le wireframe paraît propre sur la maquette, et explose au premier dev qui demande "OK mais quand y'a aucune facture, on affiche quoi ?". Le prompt 4 n'est pas optionnel, c'est lui qui rend le livrable transférable.
Aller plus loin : du wireframe au prototype
Une fois les wireframes validés, deux suites logiques. Si tu veux pousser le visuel et l'identité de marque, le pilier Claude pour le design : identité visuelle, mockups, wireframes détaille comment passer du wireframe au mockup haute fidélité. Si tu veux coder direct sans repasser par un designer, regarde le guide du vibe coding qui couvre l'enchaînement wireframe → code avec Claude.
Dernier conseil opérationnel : crée un Project Claude dédié au wireframing. Tu y stockes ton persona type, tes conventions (mobile-first par défaut, dark mode optionnel, niveau d'accessibilité visé), et les 5 prompts en template. À chaque nouvelle app, tu changes juste le brief en input. La doc pour configurer un Project Claude dédié couvre le setup pas à pas. C'est ce passage du prompt one-shot au workflow réutilisable qui change le ratio temps/qualité.
Cette méthode fait partie d'un système plus large qu'on enseigne en cohorte : prompts versionnés, Projects spécialisés par tâche, intégration MCP pour brancher Claude à ton outil de design. Si tu veux Maîtriser Claude au quotidien sur tes vrais projets, c'est le format adapté.