Un SaaS B2B se juge à la deuxième semaine d'usage, pas à la démo. Ses utilisateurs n'ont souvent pas choisi l'outil, ils l'utilisent plusieurs fois par jour, et ils le quittent dès qu'il leur fait perdre du temps. Ces dix principes viennent de la conception de [WeeFizz](/projets/weefizz/), de [Reformer Society](/projets/reformer-society/) et de quinze ans de SaaS pour des clients.
1. La première valeur avant la première configuration
Un nouvel utilisateur doit voir quelque chose d'utile avant de régler quoi que ce soit. Sur WeeFizz, le dashboard d'un nouveau client affiche des données de démonstration réalistes, et la première recommandation de taille se teste en trente secondes. La configuration vient après, quand l'utilisateur a compris pourquoi il la fait.
À mesurer : le temps jusqu'à la première valeur, pas le taux de complétion du tutoriel.
2. Une action principale par écran
Chaque écran répond à une question : que doit faire l'utilisateur ici ? Une action principale, visuellement dominante. Les autres sont secondaires. Quand deux actions se disputent la place, c'est l'écran qui est mal découpé.
3. Jamais d'écran vide
Un tableau vide, un graphique sans donnée, une liste sans élément : chaque état vide est une occasion. Il explique ce qui apparaîtra ici, propose l'action qui remplira l'écran, ou montre un exemple. Sur Reformer Society, un studio sans vidéo voit comment en importer une depuis Dropbox en trois étapes.
4. La densité se règle, elle ne s'impose pas
Les utilisateurs experts veulent voir cinquante lignes ; les débutants en veulent dix avec de l'air. Proposez un réglage de densité et des colonnes masquables plutôt que de trancher pour tout le monde. Le tableau est le composant le plus utilisé d'un SaaS : c'est là que le temps se gagne ou se perd.
5. Chaque erreur dit quoi faire
« Une erreur est survenue » est une insulte. Un message d'erreur dit ce qui s'est passé, pourquoi si c'est utile, et surtout quoi faire maintenant. Il est écrit pour un utilisateur stressé qui ne lira qu'une fois. Les codes techniques vont dans un détail repliable, pas en titre.
6. Les rôles sont visibles, pas devinés
Dans un SaaS multi-utilisateurs, chacun doit savoir ce qu'il peut faire et pourquoi il ne peut pas faire le reste. Un bouton désactivé sans explication génère un ticket. Un bouton désactivé avec « Réservé aux administrateurs » n'en génère pas.
7. La vitesse perçue est une fonctionnalité
Un SaaS utilisé cent fois par jour ne pardonne pas la lenteur. Retours visuels immédiats, chargements progressifs, actions optimistes, états intermédiaires. Et côté technique : images optimisées, requêtes groupées, cache. La vitesse se conçoit, elle ne s'optimise pas à la fin.
8. Le design system est le contrat avec les développeurs
Un SaaS vit des années et change d'équipe. Sans design system, chaque sprint ajoute une variante de bouton. Avec un système nommé de la même façon dans Figma et dans le code, la cohérence survit aux personnes. Voir Design system : par où commencer.
9. Le pricing se comprend sans appeler un commercial
Les offres, les limites, ce qui est inclus, ce qui ne l'est pas, le prix mensuel et annuel : tout doit être lisible sur une page, et exploitable par une personne qui compare trois outils un vendredi soir. Les parcours d'essai, de changement d'offre et de résiliation sont des écrans à part entière, pas des formalités. Un pricing opaque fait fuir ; une résiliation piégeuse fait perdre la réputation.
10. On mesure avant et après
Chaque changement d'interface part d'un indicateur mesuré et se vérifie sur le même indicateur. Sans mesure, le design est une opinion. Avec mesure, c'est une décision. Les analytics du produit lui-même doivent être lisibles : sur WeeFizz, la refonte des analytics a remplacé des graphiques décoratifs par des barres comparables et un indicateur de confiance explicite.
Trois pièges spécifiques au B2B
- Concevoir pour l'acheteur plutôt que pour l'utilisateur. L'acheteur voit la démo ; l'utilisateur vit avec l'outil. Les deux comptent, mais le second décide du renouvellement.
- Empiler les fonctionnalités demandées par les gros clients. Chaque fonctionnalité ajoutée pour un client est une complexité imposée à tous les autres. Préférez les réglages et les permissions.
- Négliger le back-office interne. L'équipe support utilise le produit plus que n'importe quel client. Un back-office rapide, c'est un support rapide, et un client qui reste.
Pour aller plus loin
La page UX/UI pour SaaS B2B détaille les écrans qui comptent et les formats d'intervention. Un audit UX/UI permet de mesurer où se situe votre produit sur ces dix principes.
