Associations de polices pour SaaS : le rôle d'une typographie produit

Avant de débattre de goût, il est utile de compter. Nous avons capturé les résultats pour cette requête et analysé chaque page dont le contenu était accessible, puis comptabilisé les familles recommandées par chacune.

Cette convergence est réelle, et y voir de la paresse serait une erreur. Ces polices reviennent systématiquement car elles répondent à une liste de contraintes spécifiques que la plupart des typographies ne respectent pas. Une fois cette liste connue, la convergence ainsi que la manière d'en sortir deviennent évidentes.

Les conseils en association de polices proviennent massivement du design éditorial et de marque, où l'usage d'une serif d'affichage sur un sans-serif de corps est un classique. Les interfaces produit fonctionnent différemment. La majeure partie du texte sur un écran produit se situe entre 12 et 16 pixels : labels, cellules de tableau, indices de formulaire, éléments de navigation, états vides. Il y a très peu de « d'affichage » et énormément de texte fonctionnel, petit et dense.

La réponse classique consiste donc à utiliser une seule famille pour deux rôles (un réglage plus gras et serré pour les titres, un réglage régulier pour le corps de texte), la différence étant portée par la graisse, la taille et l'approche plutôt que par un second design. Ce n'est pas un compromis. C'est ce qui donne à une interface dense un sentiment de sérénité, et cela élimine toute une catégorie de discordances subtiles.

1. Les chiffres tabulaires. Dès que vous avez un tableau, une facture, une liste de prix ou une métrique qui s'actualise, les chiffres proportionnels font osciller les colonnes et les nombres changent de largeur selon leur valeur. Une police sans chiffres tabulaires, ou une UI qui ne les active jamais, produit ces tableaux de bord instables que tout le monde a déjà vus sans jamais pouvoir en nommer la cause.
2. Une réelle séparation entre graisses adjacentes. La hiérarchie d'un produit se joue généralement entre 400 et 600 pour les petites tailles. Si le 400 et le 500 sont quasi identiques à 14px, chaque libellé semble avoir la même graisse et la hiérarchie disparaît silencieusement. Vérifiez cela à votre taille de corps réelle, et non à 48px où toutes les familles semblent correctes.
3. Une hauteur d'x importante. Le texte petit constitue la majeure partie d'un produit. Les polices avec une hauteur d'x généreuse et des ouvertures larges restent lisibles à 12 ou 13px ; les polices élégantes à faible hauteur d'x deviennent illisibles, et on compense en augmentant la taille, ce qui brise alors la densité de l'interface.
4. Des caractères sans ambiguïté. 1, l et I ; 0 et O ; rn et m. Les produits affichent des ID, des clés API, des codes d'erreur et des noms d'utilisateur. Une police où ces caractères se confondent génère des tickets de support, et ce défaut est invisible dans un spécimen de lorem ipsum.
5. Une licence couvrant une application web. Auto-hébergement, intégration dans l'app et palier de trafic prévu. C'est la contrainte que l'on découvre en dernier et qui fait le plus mal, ce qui explique en grande partie pourquoi les polices Google sous licence libre dominent toutes les listes.

Ces cinq critères éliminent la plupart des polices, et c'est précisément pour cela que les mêmes noms reviennent sans cesse. Mais notez ce qui *ne figure pas* sur la liste : rien sur l'ambiance, l'époque ou la personnalité. Les contraintes réduisent le champ à quelques dizaines de familles, et non à quatre ; le choix final vous appartient donc réellement.

Si la police de corps de tout le monde est un grotesk neutre, s'aligner sur ce standard ne vous coûte rien et s'en différencier vous apporte peu. Le lecteur ne regarde pas vos cellules de tableau en admirant la police. Deux autres leviers sont bien plus efficaces :

• Un rôle « display » véritablement différent. Un sans condensed, un vrai serif, ou un grotesk aux formes distinctes utilisé uniquement pour les titres de page et les surfaces marketing. Il apparaît rarement et définit la voix du produit ; comme il ne supporte pas de textes denses, il n'a pas à satisfaire les cinq contraintes précédentes.
• Une monospace choisie plutôt qu'héritée. Tout produit affichant du code, des ID, des horodatages ou des métriques a une police mono constamment à l'écran. La laisser par défaut selon le navigateur est une décision non prise et visible ; en choisir une est un geste simple et distinctif que personne ne copie.

Les pairings réels des kits de production suivent exactement ce schéma : un sans condensed sur un corps neutre ; un display serif sur un sans géométrique ; une seule famille pour les deux rôles quand le produit est assez dense pour qu'une seconde police crée du bruit. Ce qu'aucun d'entre eux ne fait, c'est associer deux grotesks similaires en espérant que la différence soit perceptible.

Voici trois de ces configurations rendues en direct pour comparer directement le *rôle display* : le seul endroit où la typographie d'un produit diffère significativement. Observez-les à l'extrémité « légende » de l'échelle plutôt qu'à l'extrémité « titre » : tout semble distinctif à 48px.

C'est la partie que les listicles n'abordent jamais, et c'est là que la plupart des typographies de produit échouent. Une famille parfaitement choisie sur une échelle ad hoc aura un aspect pire qu'une famille banale sur une échelle cohérente.

Fixez quatre éléments et consignez-les : une taille de base, un ratio entre les paliers, un petit ensemble de hauteurs de ligne et les graisses autorisées. Un ratio autour de 1,2 à 1,25 convient aux UI de produits denses : des ratios plus élevés créent de belles pages marketing mais ne laissent rien d'utilisable entre un titre de section et un libellé de tableau. La hauteur de ligne doit se resserrer à mesure que la taille augmente, alors que l'on s'attend souvent à l'inverse. Et limiter les graisses autorisées à deux ou trois évite qu'une base de code n'en accumule cinq.

Les interfaces sont de plus en plus générées à partir d'un brief écrit, et la typographie est le point où ces briefs sont les plus succincts. Nous avons analysé 299 fichiers DESIGN.md publics : le document qu'un agent de code lit avant d'écrire l'UI. 83 % mentionnent la typographie, ce qui semble positif jusqu'à ce que l'on regarde le contenu : 44 % n'indiquent aucune valeur de taille concrète, et 54 % contiennent au moins un adjectif imprécis, le plus souvent « clean » ou « moderne ».

« La typographie doit être raffinée » n'est pas une spécification. C'est un accord. Un agent satisfait cela avec son idée moyenne du raffiné, qui est Inter à 16px avec une hauteur de ligne de 1,5, et l'agent de tout le monde fait de même. Une famille nommée, une taille de base, un ratio et une liste de graisses autorisées modifient le résultat en quatre lignes.

1. 1

   Filtrer selon les cinq contraintes

   Chiffres tabulaires, séparation des graisses à votre taille de corps, hauteur d'x, ambiguïté des caractères, licence. Cela prend vingt minutes et élimine la majeure partie du champ avant même que le goût n'intervienne.

2. 2

   Tester à 13px dans un tableau

   Pas dans un spécimen. Créez un vrai tableau avec des chiffres, une colonne d'ID et un mélange de graisses 400 et 500. Presque tous les échecs apparaissent ici et nulle part ailleurs.

3. 3

   Décider si une seconde famille est nécessaire

   Si le produit est dense, probablement pas : concentrez vos efforts sur l'échelle. Si vous en ajoutez une, choisissez une police display qui soit indiscutablement différente.

4. 4

   Choisir la monospace délibérément

   Si du code, un ID ou un horodatage apparaît dans votre UI, cette police est constamment à l'écran et est généralement le défaut du navigateur par accident.

5. 5

   Consigner l'échelle par écrit

   Taille de base, ratio, hauteurs de ligne, graisses autorisées et règle des chiffres. Dans le repo, là où le prochain développeur et l'agent le liront tous les deux.