wensity/wensity-ui-copy

Wensity UI Copy

Les mots font partie du design. Un texte vague ou gonflé donne à une interface soignée un air générique ; un texte clair et précis rend une interface simple digne de confiance. Le test pour chaque chaîne : est-ce que cela aide quelqu'un à comprendre ou à agir ?

1. Ton

• Des mots simples. Écris comme dirait une personne serviable. "Enregistrer les modifications", pas "Persister les modifications". "Vous n'avez plus de crédits", pas "Solde de crédits épuisé".
• Les mots de l'utilisateur, pas ceux du système. "Notifications", pas "Configuration de l'envoi du webhook". Nomme les choses d'après ce que les gens en font.
• Court. Supprime chaque mot qui ne change pas le sens. Puis supprime encore.
• Casse des phrases partout : titres, boutons, éléments de menu, onglets, libellés. "Créer un nouveau projet", pas "Créer Un Nouveau Projet".
• Voix active, adressée à l'utilisateur. "Vous n'avez pas accès à ce projet", pas "L'accès à ce projet n'est pas autorisé". Quand le système a échoué, dis-le clairement : "Nous n'avons pas pu enregistrer votre fichier", pas "Le fichier n'a pas pu être enregistré".
• Calme. Pas de points d'exclamation sauf pour les vraies célébrations, pas d'excuses dans les erreurs, pas de blagues dans les états d'erreur.

2. Mots qui donnent l'impression que le texte est généré

Évite-les. Ils ne disent rien que le lecteur puisse vérifier :

• Verbes : débloquer, libérer, élever, autonomiser, booster, révolutionner, transformer, rationaliser, exploiter, réinventer, monter en flèche.
• Adjectifs : transparent, sans effort, de pointe, nouvelle génération, de classe mondiale, robuste, puissant, intuitif, innovant, tout-en-un.
• Expressions : "Dans le monde actuel en constante évolution", "Faites passer votre X au niveau supérieur", "Que vous soyez un X ou un Y", "Dites adieu à", "Ne cherchez pas plus loin".
• Formes : trois adjectifs à la suite ("Rapide. Sécurisé. Simple."), listes avec des points médians (Concevoir · Créer · Livrer), et les tirets cadratins (em dash) dans le texte du produit, y compris dans la balise <title>, la méta-description et le texte alternatif. Utilise un deux-points, une virgule ou deux phrases : "Ledgerline : factures dans n'importe quelle devise".

Remplace chacun par un fait concret : ce qu'il fait, à quelle vitesse, pour qui, avec quel résultat. "Réduit un rapport de 40 minutes à 2 minutes" bat "Boostez votre flux de travail".

3. Titres

• Un titre dit l'essentiel, pas le sujet. "Les factures sont payées 9 jours plus rapidement" bat "Fonctionnalités". "Votre espace de travail est vide" bat "Espace de travail".
• Pas de sous-titres. Ne mets pas une petite étiquette en majuscules au-dessus d'un titre ("FONCTIONNALITÉS", "TARIFICATION", "COMMENT ÇA MARCHE"). Écris un titre qui se suffit à lui-même.
• Les titres de page nomment la page pour que les gens sachent où ils sont : "Facturation", "Membres de l'équipe".

4. Boutons et liens

• Commence par un verbe et nomme le résultat : "Créer une facture", "Envoyer une invitation", "Exporter CSV". Pas "Soumettre", "OK", "Oui", "Cliquez ici", "En savoir plus" tout seul.
• Fais correspondre le bouton à ce qui se passe ensuite. Si le bouton dit "Publier", la notification dit "Publié", et la page affiche l'état publié.
• Les actions principales et secondaires doivent être clairement différentes : "Supprimer le projet" et "Annuler", pas "Oui" et "Non".
• Un à trois mots, c'est l'idéal. Un CTA peut aller jusqu'à cinq s'il ajoute un avantage concret ("Commencer gratuitement, sans carte").
• Le texte du lien a du sens tout seul (les lecteurs d'écran listent les liens hors contexte) : "Lire le guide de l'API", pas "ici".
• Les actions destructrices nomment la chose : "Supprimer 3 fichiers", "Retirer Sam de l'équipe".

5. Formulaires

• Les libellés au-dessus des champs, toujours visibles. Le texte indicatif (placeholder) n'est pas un libellé ; il disparaît quand on commence à taper.
• Les textes indicatifs montrent le format, pas des instructions : [email protected], MM / AA. Laisse-les de côté quand le libellé suffit.
• Texte d'aide sous le champ pour les règles dont l'utilisateur a besoin avant de taper : "Au moins 12 caractères".
• Marque les champs facultatifs, pas les obligatoires, quand la plupart des champs sont obligatoires : "Entreprise (facultatif)".
• Valide au blur (perte de focus) ou à la soumission, pas à chaque frappe. Affiche l'erreur à côté du champ concerné.

6. Erreurs

Chaque erreur répond à deux questions : que s'est-il passé et que faire maintenant.

Faible	Mieux
Saisie invalide	Saisis une date postérieure à aujourd'hui
Une erreur est survenue	Nous n'avons pas pu joindre le serveur. Vérifie ta connexion et réessaie.
Erreur 403	Tu n'as pas accès à ce projet. Demande à un propriétaire de t'inviter.
Échec du téléchargement	Ce fichier fait 24 Mo. La limite est de 10 Mo.
Paiement refusé	Ta carte a été refusée. Essaie une autre carte ou contacte ta banque.

• Ne blâme jamais l'utilisateur ("Tu as saisi un email invalide"). Décris la correction ("Saisis un email comme [email protected]").
• Garde les codes et les traces de pile hors du message. Mets un ID de référence à la fin si le support en a besoin.
• Conserve ce que l'utilisateur a tapé. N'efface jamais un formulaire parce qu'un champ a échoué.

7. États vides

Un état vide est la première chose qu'un nouvel utilisateur voit. Traite-le comme une intégration :

1. Dis ce qui apparaîtra ici : "Les factures que tu enverras apparaîtront ici."
2. Donne l'action unique qui le remplit : un bouton principal, "Créer une facture".
3. Facultatif : un lien pour importer, un modèle ou un court guide.

Pour les états vides "aucun résultat", dis ce qui a été recherché et comment élargir la recherche : "Aucun résultat pour 'invioce'. Vérifie l'orthographe ou efface les filtres."

8. Chargement, succès et notifications

• Chargement : dis ce qui se passe quand cela prend plus d'une seconde : "Génération du rapport…". Utilise le caractère points de suspension.
• Notifications de succès : passé de l'action, plus l'objet : "Invitation envoyée à [email protected]", "Projet supprimé. Annuler".
• Propose Annuler plutôt qu'une boîte de dialogue de confirmation pour les actions réversibles. Demande une confirmation uniquement lorsque l'action ne peut pas être annulée.
• Boîtes de dialogue de confirmation : le titre pose la vraie question ("Supprimer le rapport 'Q3'?"), le corps énonce la conséquence ("Cela le supprime pour tout le monde. Tu ne peux pas annuler cela."), les boutons nomment l'action ("Supprimer le rapport" / "Annuler").

9. Nombres, dates et unités

• Utilise des chiffres : "3 fichiers", pas "trois fichiers".
• Formate avec la locale de l'utilisateur : Intl.NumberFormat et Intl.DateTimeFormat (ou toLocaleString) au lieu de chaînes construites à la main.
• Temps relatif pour les événements récents ("il y a 2 min"), dates absolues pour les plus anciennes ("4 mars"), et l'horodatage complet dans une infobulle.
• Accorde correctement au pluriel : "1 fichier", "2 fichiers", "0 fichier". Utilise Intl.PluralRules ou une fonction utilitaire, jamais "fichier(s)".
• Garde les nombres et les unités ensemble avec un espace insécable (10 Mo en HTML, "10\u00A0Mo" en JavaScript) pour qu'ils ne soient jamais séparés.

10. Contenu réaliste de substitution

Lorsque tu conçois sans contenu réel, écris un contenu qui a l'air réel :

• Noms et données spécifiques : "Maya Chen, Conceptrice produit chez Northwind", "12 480,00 €", "Facture FAC-2041". Pas "Jean Dupont", "XX €", "Lorem ipsum".
• Longueurs réalistes, y compris certaines longues, pour que la mise en page soit testée : un nom de 40 caractères, une description de 3 lignes à côté d'une description de 1 ligne.
• N'invente jamais de preuves. Pas de logos clients fictifs, d'évaluations par étoiles, de décomptes d'utilisateurs ou de témoignages présentés comme réels. Utilise des espaces réservés marqués ([Citation client], [Logo]) ou demande à l'utilisateur les vrais.
• Correspond au monde du produit. Les données d'exemple d'un outil de développement sont des dépôts et des déploiements ; celles d'une application clinique sont des rendez-vous et des patients.

11. Accessibilité dans le texte

• Chaque bouton à icône uniquement reçoit un nom accessible : aria-label="Fermer la fenêtre de dialogue".
• Le texte alternatif décrit ce qu'une image montre lorsqu'elle porte des informations ("Diagramme à barres : revenus en hausse de 24 % depuis janvier"). Les images décoratives reçoivent alt="".
• Ne te fie pas uniquement aux mots de couleur ("clique sur le bouton vert").
• Développe les abréviations la première fois, sauf si le public les utilise quotidiennement.

12. Vérifie avant de terminer

• Pas de mots de remplissage de la section 2, pas de slogans en trois adjectifs, pas de tirets cadratins (em dash) dans les chaînes d'interface.
• Chaque titre énonce un point ; pas de sous-titres.
• Chaque bouton commence par un verbe et nomme son résultat.
• Chaque erreur dit ce qui s'est passé et quoi faire.
• Chaque état vide s'explique et propose l'action suivante.
• Casse des phrases partout.
• Le contenu d'exemple est spécifique, de longueur variée, et ne contient aucune preuve inventée.
• Les contrôles à icône uniquement et les images significatives ont un texte accessible.