Schémas d'états vides qui réduisent la confusion et guident l'utilisateur vers la prochaine étape de configuration réussie : copy, mise en page et checklists faciles à appliquer.
Un écran vide n'est pas neutre. Il crée une pause où les gens commencent à deviner quoi faire, s'ils ont raté une étape, ou si le produit fonctionne du tout. Pendant la configuration, cette pause coûte cher : elle transforme « je commence » en « je reviendrai plus tard ».
Un état vide est ce que voit un utilisateur quand il n'y a encore rien à afficher parce qu'il n'a rien créé, importé ou connecté. Ce n'est pas un écran de chargement, un message d'erreur ou un avertissement de permissions. C'est le moment juste avant la valeur, quand l'app doit aider l'utilisateur à atteindre un premier résultat significatif.
Un bon état vide a un seul objectif : faire avancer l'utilisateur vers l'action suivante réussie avec le moins de réflexion possible. Le mot « réussi » compte. L'étape suivante doit produire un vrai résultat (un premier projet, une source de données connectée, un premier élément créé), pas un formulaire sans suite ou une visite guidée vague.
Ces moments apparaissent plus souvent que les équipes ne le pensent : première connexion après l'inscription, un espace de travail tout neuf, un onglet de fonctionnalité sans éléments (projets, clients, fichiers), ou un parcours de configuration où l'import a été sauté et rien n'existe.
Quand un état vide fait son travail, il répond vite à trois questions :
Exemple : dans Koder.ai, un nouvel utilisateur peut ouvrir un espace de travail vierge et ne voir aucune app. Un bon état vide indique clairement que rien n'a été créé, propose une action suivante évidente comme « Créez votre première app », et ajoute une petite note de sécurité (par exemple, que l'export du code source et les snapshots existent une fois qu'ils commencent). L'objectif est de transformer « rien ici » en « je peux atteindre un premier résultat fonctionnel ».
Pour un utilisateur novice, un écran vide peut donner l'impression que l'app s'est bloquée ou qu'il a fait quelque chose de mal. L'esprit comble vite le vide, et généralement pas en votre faveur.
La plupart des gens se posent silencieusement les mêmes questions :
Les émotions derrière ces questions dictent le comportement. L'incertitude fait hésiter. La peur de mal faire pousse à éviter le bouton principal. L'impatience les fait fermer l'app si une étape claire n'apparaît pas en quelques secondes.
Les états vides pour nouveaux utilisateurs et pour utilisateurs avancés ne résolvent pas les mêmes problèmes. Les nouveaux ont besoin de contexte et de sécurité parce qu'ils ne connaissent pas encore votre vocabulaire. Les utilisateurs réguliers veulent de la vitesse : un moyen rapide de créer un nouvel élément, d'importer des données ou de répéter une action familière.
Les états vides de configuration diffèrent aussi des états d'erreur et de chargement. Le chargement dit « attendez, quelque chose se passe ». L'erreur dit « quelque chose a échoué, voici pourquoi ». La configuration dit « rien n'est encore là, et c'est normal. Voici comment commencer. »
Un exemple concret : si quelqu'un ouvre un nouvel espace dans Koder.ai et voit une page Projets vide, il ne pense pas aux fonctionnalités. Il se demande « je commence par un prompt, j'importe du code, ou je choisis un template, et est-ce que ça va tout casser ? ». Votre état vide doit répondre sans envoyer vers la documentation.
Un bon état vide ne donne pas l'impression d'être vide. Il agit comme un panneau : « Voici ce que c'est, et voici le clic suivant. »
Une structure efficace dans la plupart des parcours de configuration comprend trois parties :
Gardez l'explication concise. Si vous avez besoin d'un paragraphe pour expliquer l'écran, vous demandez trop de réflexion à l'utilisateur. Visez 1 à 2 phrases courtes avec des mots simples comme « Ajoutez votre premier projet » ou « Créez votre premier espace de travail ».
Ensuite, rendez l'étape suivante évidente avec un seul bouton primaire. Si vous montrez trois boutons égaux, vous demandez à l'utilisateur de choisir un chemin avant qu'il n'ait compris la page. Si vous devez offrir des alternatives (importer, template, ignorer), gardez-les visuellement plus discrètes que l'action principale.
Utilisez la ligne de réassurance pour supprimer les peurs courantes : faire une erreur, perdre du temps, ou nécessiter des compétences techniques. De petits indices sur ce qui se passe ensuite et ce qui peut être annulé aident davantage qu'une longue explication.
Exemple de texte pour un écran « Projets » destiné à un nouvel utilisateur :
Titre : Lancez votre premier projet
Explication : Les projets contiennent la configuration et les releases de votre app.
Action principale : Créer un projet
Réassurance : Prend environ 2 minutes. Vous pouvez renommer ensuite.
Si votre produit propose plusieurs façons de démarrer (build depuis le chat, import, ou template, comme des outils tels que Koder.ai), gardez « Créer » par défaut et placez « Importer » et « Utiliser un template » comme actions secondaires en dessous.
Les états vides échouent quand le texte parle de fonctionnalités au lieu de ce que l'utilisateur obtient. Vos mots doivent répondre rapidement : Quel est cet écran ? Pourquoi devrais-je agir ici ? Que dois-je faire ensuite ?
Une formule simple pour les titres est Résultat + objet. Nommez le résultat et la chose qu'ils vont créer, pas votre nom interne de fonctionnalité.
Pour le corps du texte, utilisez ce que c'est + pourquoi ça compte en une ou deux phrases :
"Les clients sont les personnes à qui vous vendez. Ajoutez-en un maintenant pour pouvoir envoyer une facture et suivre les paiements."
Les CTA doivent commencer par un verbe clair et inclure un nom spécifique. Évitez les boutons vagues comme « Commencer » quand il existe plusieurs chemins.
Ajoutez un micro-texte juste à côté du choix qui semble risqué. De petites réassurances font souvent plus que de longues explications :
Si votre produit génère du contenu pour l'utilisateur (comme Koder.ai), donnez des attentes pour que les gens sachent qu'ils ne s'engagent pas à une version finale : « Nous créerons un premier brouillon. Vous pourrez revoir et éditer avant de déployer. »
Un bon état vide doit se lire comme un panneau, pas comme une affiche. La mise en page a besoin d'un ordre clair pour que l'on puisse comprendre d'un coup d'œil et agir.
Utilisez une hiérarchie simple qui suit le parcours visuel : titre, une phrase courte, un CTA primaire, puis une action secondaire plus discrète (importer, template, ignorer).
Gardez le bouton principal proche du message. Si l'utilisateur doit lire, défiler, puis décider, il s'arrête souvent. Un bloc serré (titre + texte + CTA) avec plus d'espace entre ce bloc et le reste (navigation, pied de page, panneaux latéraux) fonctionne bien.
Les icônes et petites illustrations peuvent faciliter la lecture, mais seulement si elles ajoutent du sens. Une icône de dossier à côté de « Pas de projets » est utile. Une mascotte aléatoire l'est moins. Si vous utilisez une illustration, gardez-la petite et placez-la au-dessus du titre pour qu'elle ne concurrence pas le CTA.
Un des schémas les plus puissants est de montrer un tout petit aperçu du succès : une carte d'exemple, une ligne de tableau démo, ou une tuile d'exemple atténuée. Dans un outil comme Koder.ai, l'écran vide « Apps » pourrait montrer une tuile d'app d'exemple (nom, statut, dernière mise à jour) pour que l'utilisateur comprenne immédiatement ce qu'il va créer.
Quand quelqu'un arrive sur un écran vide, il veut généralement une des trois choses : commencer à zéro, récupérer des données, ou aller vite avec un démarrage prédéfini. Les bons états vides clarifient ces chemins sans forcer l'utilisateur à étudier le produit.
Mettez « Créer » en avant quand la première vraie victoire est de créer quelque chose : un projet, un espace, une page ou le premier enregistrement. Cela marche mieux quand l'utilisateur peut finir rapidement et que l'action est réversible.
Si la création prend plus de temps, découpez-la en une première petite étape (par exemple « Créer un brouillon ») pour que l'utilisateur avance sans se sentir enfermé.
Mettez « Importer » en avant quand la plupart des nouveaux utilisateurs arrivent avec un système, un fichier ou un compte à connecter. L'état vide doit indiquer ce que l'import supporte et ce qu'ils obtiennent ensuite (par exemple, champs mappés et éléments créés).
Une méthode pratique pour choisir le CTA principal est de se baser sur le contexte. Si l'utilisateur vient d'un contenu de migration, mettez l'accent sur Importer. S'il a cliqué sur un bouton « nouveau projet » vide, mettez l'accent sur Créer. Si la configuration est complexe, mettez en avant Template.
Mettez les templates en avant quand votre produit propose des points de départ courants et que les utilisateurs veulent surtout adapter plutôt que concevoir. Nommez les templates par résultat (« Pipeline de ventes », « Planificateur hebdo »), pas par fonctionnalités.
Une option « Essayer avec des données d'exemple » réduit la peur. Précisez qu'on peut le supprimer. Pour un builder orienté chat comme Koder.ai, un projet d'exemple peut montrer la forme d'une app fonctionnelle avant que l'utilisateur écrive son propre prompt.
Les écrans vides ne sont pas neutres. Les meilleurs rendent l'action suivante évidente, sûre et rapide.
Exemple : si quelqu'un ouvre un CRM neuf et voit l'onglet « Contacts » vide, la victoire la plus rapide est « Ajoutez votre premier contact. » Limitez aux champs nom + e-mail, proposez « Importer CSV » en secours, et rassurez que les champs sont modifiables plus tard.
La plupart des états vides « bloqués » échouent pour une raison : ils rendent la prochaine action risquée ou peu claire.
Si vous affichez trois boutons qui semblent aussi importants, les utilisateurs hésitent. Choisissez une action primaire et une secondaire. Mettez le reste derrière « Plus d'options » discret.
« Dashboards puissants, rôles flexibles, paramètres avancés » ne dit pas quoi faire maintenant. Remplacez par le résultat immédiat après le clic.
Exemples :
Les longs formulaires dans un état vide ressemblent à un engagement. Si vous avez besoin de détails, récupérez-les plus tard. Commencez par l'étape la plus petite qui produit quelque chose de visible.
Au lieu de demander nom, taille d'entreprise, rôle et objectifs avant que quoi que ce soit ne charge, demandez seulement « Nom du projet » et laissez le reste optionnel après la création de la première page.
L'humour a sa place, mais pas quand l'utilisateur a besoin de clarté. « Rien à voir ici » gaspille le moment. Dites précisément ce qui se passera après le clic, et ce qui ne se passera pas.
Certains utilisateurs ne peuvent pas créer depuis zéro. Proposez un vrai chemin de secours : importer, template, ou un exemple. Par exemple, si quelqu'un utilise Koder.ai et n'a pas d'idée, « Commencer avec une app d'exemple » peut l'amener à un écran fonctionnel sans écrire un cahier complet.
Un nouvel utilisateur doit comprendre ce qu'est l'écran, pourquoi ça compte et que faire ensuite en environ cinq secondes.
La réassurance transforme l'hésitation en action. Ajoutez une petite ligne près du CTA qui réduit la peur, comme « Vous pouvez modifier cela plus tard » ou « Rien n'est publié tant que vous n'avez pas confirmé. » Restez calme et précis.
Un test simple : demandez à un collègue de regarder l'écran pendant cinq secondes, puis de vous dire ce qu'il pense qu'il se passera s'il clique sur le bouton principal. S'il ne peut pas répondre, resserrez le texte ou la hiérarchie.
Si vous construisez des flux de configuration dans un builder orienté chat comme Koder.ai, la même checklist s'applique. L'état vide doit inviter à une seule action réussie : démarrer depuis un template, importer des données, ou générer une première version modifiable en toute sécurité.
Un fondateur solo s'inscrit à Koder.ai et ouvre un espace de travail neuf. Il arrive sur un écran Projets à zéro app et ne sait pas encore à quoi ressemble un bon résultat.
Au lieu d'un tableau vide, l'état vide affiche une promesse courte, une étape suivante claire et une petite note de sécurité. Voici un exemple du texte et du CTA (estimez les durées et validez-les) :
Your workspace is empty.
Create your first app in 5 minutes. Start with a template or describe what you want in plain English.
[Create your first app]
Secondary: Import existing code | Browse templates
Note: You can export the source code anytime.
Après que le fondateur a cliqué sur Create your first app, l'écran suivant pose une question simple : « What are you building? » avec un seul champ et 2 prompts d'exemple (comme « CRM for a small agency » ou « Landing page with signup »). Gardez le chemin étroit : un champ évident, un bouton évident.
L'écran deux peut être un bref plan (fonctionnalités, pages, données), suivi d'une étape de build et d'un aperçu fonctionnel. Le premier moment de réussite est quand l'utilisateur peut faire une vraie action dans cet aperçu, comme ajouter un enregistrement ou soumettre un test d'inscription.
Une fois des données présentes, les utilisateurs retournant ne doivent plus voir le même état vide. La page Projets peut basculer vers une vue « apps récentes » avec une action rapide proéminente (par exemple New app) et des actions plus petites (comme Snapshots ou Deploy) selon ce qu'ils ont fait la dernière fois.
Pour savoir si votre état vide fonctionne, suivez quelques métriques :
Choisissez un parcours de configuration à améliorer cette semaine. Préférez celui avec la plus forte chute ou celui que les nouveaux utilisateurs voient en premier. Réécrivez son état vide pour qu'il réponde vite à trois questions : Qu'est-ce que c'est ? Pourquoi le faire maintenant ? Quel est le prochain clic ?
Gardez le changement petit. Vous ne refondez pas l'onboarding. Vous faites en sorte que la première action réussie soit évidente.
Un plan simple sur une semaine :
Après une première victoire, standardisez. Créez un court pattern interne pour les états vides : espacements, style de titre, règles pour icônes/illustrations, et une mise en page CTA cohérente. Quand les équipes suivent la même structure, les utilisateurs l'apprennent une fois et vont plus vite partout.
Si vous construisez une nouvelle app et voulez prototyper vite des étapes de configuration, Koder.ai (koder.ai) peut vous aider à rédiger un flux en Planning Mode et générer une première version à tester, puis itérer là où les gens hésitent vraiment.
Un état vide est ce que voient les utilisateurs quand il n'y a encore rien à afficher parce qu'ils n'ont rien créé, importé ou connecté. Il doit expliquer à quoi sert l'écran et indiquer l'action suivante qui réussira, plutôt que de laisser l'utilisateur deviner.
Un écran de chargement indique « attendez, quelque chose se passe » et un état d'erreur dit « quelque chose a échoué, voici pourquoi ». Un état vide de configuration dit « rien n'est encore là, et c'est normal », puis guide l'utilisateur pour créer, importer ou démarrer depuis un template afin d'atteindre un premier résultat concret.
Visez à répondre rapidement à trois choses : ce qu'est cet écran, pourquoi il est vide et que faire ensuite. Si les utilisateurs ne peuvent pas comprendre cela en quelques secondes, ils vont hésiter, penser qu'ils ont fait une erreur ou quitter.
Utilisez une structure simple : une courte explication de l'objet de la zone, une action primaire évidente et une ligne de réassurance qui réduit la peur ou l'effort. Gardez le texte concis pour que l'utilisateur n'ait pas besoin de lire un long paragraphe pour savoir où cliquer.
Privilégiez un bouton primaire qui correspond à l'étape la plus courante, et rendez tout le reste clairement secondaire. Si vous affichez plusieurs boutons d'importance égale, les gens ont tendance à se figer parce qu'ils ne savent pas quel chemin est « le bon ».
Mettez « Créer » en avant quand démarrer de zéro conduit rapidement à un résultat visible (premier projet, premier enregistrement). Privilégiez « Importer » quand la plupart des nouveaux utilisateurs ont déjà des données ailleurs. Proposez « Template » quand la rapidité prime et qu'il existe des points de départ éprouvés.
Rédigez les titres comme « résultat + objet », par exemple « Créez votre premier projet » plutôt que des labels de fonctionnalité comme « Projets ». Pour le texte, ajoutez une phrase expliquant ce qui se passe après le clic afin que l'utilisateur puisse prévoir le résultat.
Placez le titre, une phrase courte et le bouton primaire dans un bloc compact avec une hiérarchie visuelle claire. Gardez les actions secondaires plus discrètes et évitez de pousser le bouton principal trop bas sur la page où il faudrait défiler pour le trouver.
Ajoutez une courte note de sécurité près de l'action, comme « Vous pouvez modifier cela plus tard » ou « Rien n'est publié tant que vous n'avez pas confirmé ». Dans des outils comme Koder.ai, il peut aussi être utile de mentionner des actions réversibles (snapshots/rollback) ou la possibilité d'exporter le code source une fois qu'on a commencé.
Suivez la fréquence d'affichage de l'écran vide, le taux de clics sur le CTA principal et le taux d'atteinte du jalon visé. Mesurez aussi le temps jusqu'au premier succès et le taux d'abandon entre l'état vide et l'étape suivante : un état vide peut recevoir des clics sans pour autant générer de résultats réels.