Comment concevoir des tableaux de prix clairs

Un tableau de prix utile permet de répondre à trois questions sans ouvrir une calculatrice ni un second onglet : quelle offre convient à mon travail ? Combien vais-je réellement payer ? Que se passe-t-il si je la choisis ?

Cela semble simple jusqu’à ce que les vraies caractéristiques du produit entrent dans la mise en page. Une offre comprend cinq éditeurs, une autre facture par éditeur, la facturation annuelle s’affiche sous forme d’équivalent mensuel et la fonctionnalité décisive est enfouie sous douze coches identiques. Les cartes peuvent être soignées et le choix rester difficile.

Les exemples détaillés utilisent Fieldnote, un service de collaboration fictif.

Définissez le choix avant de dessiner les cartes

Écrivez en une phrase la décision attendue du visiteur. Pour Fieldnote : choisir une offre d’espace de travail pour un chercheur indépendant, une petite équipe projet ou une organisation ayant besoin d’une administration centralisée.

Ces besoins de fonctionnement diffèrent. Ils constituent un point de départ plus utile que de décider que toute page tarifaire doit avoir trois colonnes. Un produit avec une seule formule payante a peut-être besoin d’expliquer son prix plutôt que de comparer. Un service proposant plusieurs produits distincts a peut-être besoin d’un premier sélecteur de produit. Juxtaposer des achats fondamentalement différents en colonnes peut suggérer qu’ils sont interchangeables alors qu’ils ne le sont pas.

Demandez au responsable produit quels faits modifient réellement le choix. Dans notre exemple, ce sont les projets actifs, les éditeurs inclus, l’accès invité et l’administration. Le stockage varie aussi, mais il ne déterminera probablement pas la première décision du public visé. Cette distinction donne un ordre à la page : établir d’abord l’adéquation, puis exposer les détails permettant de la vérifier.

Conservez une petite fiche de référence en dehors du design. Notez pour chaque offre son nom, son public, son unité de facturation, la quantité incluse, ses limites, les conditions de passage à une offre supérieure et le parcours d’achat. Si un élément n’est pas décidé dans la source, indiquez-le comme tel. Une belle maquette est un très mauvais endroit pour trancher accidentellement une politique commerciale manquante.

La fiche protège aussi contre les mises à jour incohérentes. Si l’équipe change le nombre d’éditeurs inclus, le résumé de l’offre, la ligne du comparatif, le calculateur et la FAQ peuvent tous nécessiter une modification. Traitez-les comme des représentations d’un même fait, pas comme des textes indépendants qui contiennent par hasard le même nombre.

Tableaux de prix : présélectionner d’abord, comparer ensuite

Les cartes d’offres et la matrice de fonctionnalités remplissent deux fonctions différentes. Les cartes aident à établir une présélection. La matrice permet de confronter celle-ci à des exigences précises. Tout placer dans les cartes produit de longues colonnes dont les différences deviennent difficiles à repérer.

Les recommandations de Figma sur les pages tarifaires distinguent les présentations concises des offres du tableau comparatif détaillé et conseillent de préciser l’unité de facturation près du prix. C’est une base utile pour la structure présentée ici. Les recommandations de Figma sur les pages tarifaires.

Pour Fieldnote, la carte Solo peut présenter le travail sur des projets indépendants, puis le prix, la limite de projets actifs et l’accès invité. La carte Team peut présenter la recherche partagée, puis le prix, les éditeurs inclus et la capacité commune de projets. La carte Organization peut expliquer l’administration centralisée et son parcours d’achat accompagné par l’équipe commerciale. Inutile d’inventer un prix public sur cette dernière carte si le modèle commercial exige un devis.

Gardez un ordre d’information constant, même lorsque les valeurs diffèrent. Si une carte place ses modalités de facturation sous le bouton et une autre à côté du prix, le lecteur doit chercher leur relation. L’alignement devient une explication : une même position désigne le même type d’information.

Lisez la page tarifaire de GitHub en deux temps

La page tarifaire de GitHub fournit un exemple concret de la distinction entre résumé d’offre et comparaison détaillée. La zone des offres établit les choix et les parcours d’achat disponibles ; le comparatif de fonctionnalités en dessous apporte un autre niveau de détail. Les prix capturés illustrent cette structure ; consultez la page en ligne pour les conditions actuelles.

Examinez les deux zones avec des questions différentes. Dans le résumé, pouvez-vous identifier une option plausible pour votre équipe ? Dans la matrice, pouvez-vous vérifier l’exigence qui suffirait à l’écarter ? Cette division est utile parce qu’une carte d’introduction et une vérification d’achat n’ont pas la même densité d’information. Une carte qui reprend chaque ligne de la matrice cesse d’être un résumé.

Demandez à un acheteur potentiel de choisir une offre adaptée et d’expliquer l’engagement ; ces réponses testent ce que la présentation communique.

Calculez la facture que le lecteur choisit réellement

Pour un exemple distinct facturé par siège, imaginons un service fictif nommé SeatMeter, dont l’offre s’affiche à 12 $ par éditeur et par mois, facturés annuellement, avec un minimum de cinq éditeurs. Une équipe de trois personnes ne doit pas nécessairement 36 $ chaque mois. Selon ces conditions, l’engagement annuel minimal est de 12 $ × 5 × 12 = 720 $.

C’est souvent ici qu’une présentation tarifaire échoue, même si chaque nombre pris séparément est exact. La hiérarchie visuelle rend l’équivalent mensuel mémorable et le paiement réel presque invisible. Demandez à quelqu’un d’expliquer ce qu’il pense devoir payer aujourd’hui. S’il répond par le tarif plutôt que par la facture, agrandir le tarif ne résoudra pas le malentendu.

Ne laissez pas une pastille d’économie masquer la base de comparaison. Si l’option annuelle économise vingt pour cent par rapport à douze paiements mensuels, précisez le tarif mensuel utilisé. Si une promotion ne s’applique qu’à la première période, gardez cette condition près du montant promotionnel. Une pastille à l’allure permanente associée à une offre temporaire crée une attente qu’une note de bas de page ne suffira peut-être pas à corriger.

La même rigueur s’applique à la capacité incluse. « Cinq éditeurs inclus » et « minimum de cinq éditeurs payants » peuvent donner la même taille d’équipe initiale tout en décrivant des règles commerciales différentes. Inscrivez la vraie règle dans la fiche de référence, puis donnez le même sens à la carte, à la matrice et au passage vers le paiement.

Une tarification par espace de travail se calcule autrement

Gardez ensemble montant, devise, unité de facturation et engagement. Pour une souscription annuelle présentée en équivalent mensuel, le montant annuel total doit figurer dans le même groupe visuel.

Supposons que Fieldnote Team coûte 30 $ par espace de travail chaque mois avec une facturation mensuelle. L’offre annuelle distincte coûte 288 $ par espace de travail et par an, soit 24 $ par mois. Une carte annuelle claire peut afficher l’équivalent mensuel comme montant principal, immédiatement suivi d’une phrase indiquant que 288 $ sont facturés annuellement. Le visiteur ne doit pas avoir à déduire que douze paiements de 24 $ sont possibles.

La différence entre prix par espace et prix par siège mérite la même attention. « 24 $ par mois » est incomplet si une équipe de six personnes paiera en réalité six fois cette somme. Indiquez si le prix comprend un nombre fixe d’éditeurs, s’applique à chaque éditeur ou démarre à une quantité minimale. Placez l’hypothèse de quantité dans la zone du prix plutôt que dans une infobulle éloignée.

Pour un usage variable, expliquez la limite avant d’ajouter un calculateur. Sans base visible, un calculateur peut donner une précision trompeuse à un prix incertain. Précisez l’usage inclus, ce qui déclenche un supplément et si l’estimation comprend les options. S’il n’existe pas de tarif stable à calculer, expliquez plutôt les informations dont l’équipe commerciale a besoin.

Ne mélangez pas plusieurs unités sur une même ligne du comparatif. Une cellule « 10 » et une autre « Illimité » sont ambiguës si la ligne n’indique pas ce que l’on compte et sur quelle période. « Projets actifs » diffère de « Projets créés par mois ». Cette distinction peut changer l’achat même lorsque les nombres semblent identiques.

Traitez le sélecteur de facturation comme un changement de conditions

Passer de la facturation mensuelle à annuelle doit mettre à jour simultanément tous les faits concernés. Ce n’est pas simplement une animation du montant principal. Le total annuel, l’explication des économies, la formulation de l’engagement et la destination de l’action d’achat doivent tous rester cohérents avec l’état choisi.

Dans l’exemple Fieldnote, douze mois de facturation mensuelle totalisent 360 $, contre 288 $ avec la facturation annuelle. La différence est de 72 $, soit vingt pour cent du total mensuel sur l’année. Si le design affiche cette économie, gardez sa base explicite. Comparer le montant annuel réduit à un autre tarif promotionnel raconterait une autre histoire.

Le choix actif exige un libellé et un état sans ambiguïté. Deux mots à côté d’un petit interrupteur peuvent laisser un doute : le libellé de gauche décrit-il la valeur actuelle ou l’autre choix possible ? Une commande segmentée avec une option visiblement sélectionnée est souvent plus facile à expliquer dans un prototype. Quel que soit le traitement retenu, l’état sélectionné doit rester identifiable au clavier et ne pas reposer uniquement sur la couleur.

Actionnez le sélecteur en regardant une offre plus bas dans la page. Pouvez-vous encore savoir quelle période de facturation s’applique ? Répéter le libellé près d’un long comparatif peut être plus utile qu’une commande disparue très loin au-dessus. La répétition est justifiée lorsqu’elle empêche le prix de perdre son contexte.

Décidez aussi de ce qui reste stable. L’ordre des offres et les limites de fonctionnalités ne doivent pas changer simplement parce que la fréquence de facturation change, sauf si l’offre réelle change. Un réarrangement inattendu complique la comparaison des états et peut donner l’impression que le service s’est transformé sous les yeux du lecteur.

Construisez des lignes honnêtement comparables

Chaque ligne doit poser une question et y répondre pour chaque offre. « Capacité de projets » peut contenir un nombre. « Accès invité » peut contenir « Inclus » ou « Non inclus ». « Assistance » demande une description si une offre propose l’e-mail et une autre un interlocuteur nommé. Une coche seule n’exprime pas ces différences.

Utilisez la même unité et le même niveau de précision sur toute une ligne. Si la colonne Solo indique « Trois projets actifs », n’écrivez pas « De la place pour grandir » dans Team. La seconde formule évite la comparaison que le tableau est précisément censé permettre. Réservez les formulations promotionnelles à l’explication autour et placez la limite réelle dans la cellule.

Distinguez absence et incertitude. Un tiret peut signifier indisponible, non applicable, non communiqué ou zéro. Choisissez des mots explicites lorsque la différence compte. Si vous utilisez un symbole compact, définissez clairement son sens et assurez-vous que les technologies d’assistance le reçoivent aussi. Un acheteur ne doit jamais deviner si une cellule vide est une limite ou une erreur de publication.

Les noms des fonctionnalités doivent aussi rester stables. Appeler une même capacité « Dossiers partagés » dans la première offre et « Espaces collaboratifs » dans la seconde peut créer une amélioration apparente qui n’existe pas. Lorsqu’une capacité change réellement, décrivez le changement : davantage de membres, un historique plus long, des droits différents ou un autre engagement de service.

Regroupez les lignes autour de questions reconnaissables. Fieldnote pourrait proposer des sections sur le travail de projet, la collaboration et l’administration. Les groupes doivent aider à trouver une réponse, pas reproduire l’organigramme interne de l’équipe produit. Si un acheteur raisonne en partage d’accès, rendez ce parcours évident, même si plusieurs équipes d’ingénierie gèrent les fonctionnalités correspondantes.

Soyez prudent avec « Tout ce que comprend l’offre précédente ». Cela raccourcit une carte, mais force le lecteur à regarder ailleurs pour comprendre l’offre supérieure. C’est parfois acceptable dans un bref aperçu. Dans une matrice, répéter la vraie valeur est généralement plus utile, car chaque ligne reste comparable indépendamment.

Donnez une raison à votre recommandation

Une offre mise en avant doit expliquer à qui elle convient. « Pour les équipes qui partagent leurs recherches entre plusieurs projets » donne une raison d’envisager Fieldnote Team. « Meilleur rapport qualité-prix » demande d’accepter un jugement sans en connaître la base. « La plus populaire » est une affirmation factuelle qui exige des éléments à l’appui ; elle ne doit pas remplacer une recommandation par une décoration.

Utilisez l’accent visuel pour proposer un point de départ tout en laissant les alternatives lisibles. Une bordure plus forte, un petit libellé ou un changement de surface discret peuvent suffire. Agrandir la carte centrale au point de rendre les conditions voisines difficiles à parcourir est un mauvais compromis. L’utilisateur doit encore comparer l’option mise en avant aux autres.

Examinez la page sans cette mise en avant. Si l’offre devient incompréhensible, l’accent visuel portait trop d’explication. Les noms des offres, les descriptions des publics et les différences visibles doivent permettre un choix raisonnable avant que la couleur n’ajoute une priorité.

Gérez les écrans étroits sans masquer le compromis

Empiler les cartes d’offres est simple ; préserver la comparaison l’est moins. Lorsque chaque offre occupe un écran distinct, se souvenir si la première comprenait une fonctionnalité devient une partie du travail. Ne supposez pas qu’une disposition verticale propre rend automatiquement la comparaison facile.

Pour un petit nombre d’offres, conservez le même ordre de fonctionnalités dans les cartes empilées. Pour une matrice plus longue, envisagez un comparatif étroit permettant de choisir deux offres ou un tableau à défilement horizontal dont l’orientation est claire. Le bon choix dépend de ce que les visiteurs font surtout : lire une offre ou comparer plusieurs valeurs précises.

Un accordéon peut réduire la longueur initiale, mais il masque aussi des informations. Gardez les limites essentielles et les modalités de facturation hors des sections repliées. Si la personne doit ouvrir chaque offre pour savoir laquelle comprend l’accès invité, l’accordéon n’a fait que répartir le même effort sur davantage d’interactions.

Lorsque vous utilisez un vrai tableau de données, préservez ses relations structurelles. Le tutoriel du W3C explique comment associer les cellules d’en-tête aux cellules de données afin de rendre ces relations disponibles aux technologies d’assistance. Une grille de textes visuellement alignés n’est pas une implémentation équivalente. Le tutoriel W3C sur les tableaux accessibles.

Testez la version étroite avec une comparaison concrète : trouver l’option la moins chère permettant six éditeurs et vingt projets actifs. Ces exigences fictives révèlent si la présentation conserve les informations nécessaires au choix. Vérifier seulement que la page tient dans la fenêtre ne répondra pas à cette question.

Faites correspondre l’action à l’étape suivante

Le bouton doit décrire l’action immédiate que le visiteur peut réellement effectuer. Commencer un essai, créer un espace gratuit, choisir un abonnement payant et contacter l’équipe commerciale sont des étapes différentes. Réutiliser « Commencer » partout donne une rangée cohérente de boutons, mais laisse l’interaction vague.

Placez les conditions importantes près de l’action concernée. Si un essai exige un moyen de paiement, dites-le avant de poursuivre. Si une offre d’organisation commence par un échange, évitez un bouton qui suggère un paiement immédiat. Le but est de créer une attente exacte, pas d’expliquer tout le processus d’achat dans la carte.

Pensez aux personnes déjà abonnées. Un tableau tarifaire public générique peut les envoyer vers une nouvelle inscription en double. L’implémentation finale aura peut-être besoin d’un état d’offre actuelle ou d’un accès aux paramètres du compte. Même si le prototype ne gère pas les comptes, notez cet état pour que le design ne soit pas évalué uniquement pour les nouveaux visiteurs.

N’utilisez pas un bouton désactivé pour chaque choix indisponible. Si l’éligibilité dépend d’une condition du compte, expliquez-la. Une commande désactivée sans explication ne permet pas de savoir s’il s’agit d’une limite, d’une erreur temporaire ou d’une règle intentionnelle.

Les cartes GitHub capturées rendent cette distinction concrète. Team propose « Continue with Team » ; Enterprise propose à la fois un essai et un contact commercial. Cette seconde carte représente deux parcours vers la même offre, pas deux fonctionnalités différentes. Pendant la revue, suivez chaque parcours et vérifiez les informations que le visiteur doit fournir ensuite. Une couleur de bouton cohérente peut préserver le rythme visuel tout en gardant des libellés précis sur l’étape suivante.

Examinez une version avec des tâches de décision

Une revue visuelle devient plus utile lorsque chaque participant a une question à résoudre. Donnez à l’un le scénario indépendant, à l’autre celui d’une équipe qui grandit. Demandez-leur de choisir une offre et d’expliquer les faits qui motivent leur choix. Leur raisonnement révèle des ambiguïtés qu’une demande ouverte de commentaires peut manquer.

Pour Fieldnote, une tâche peut concerner un chercheur avec deux projets et plusieurs invités. Une autre peut impliquer six éditeurs, tandis qu’une troisième exige une administration à l’échelle de l’organisation. Incluez un scénario qui devrait écarter l’offre mise en avant. Sinon, la revue vérifie seulement si l’accent visuel fonctionne, pas si le comparatif permet une conclusion différente.

Demandez ensuite à chacun le montant facturé immédiatement et l’engagement de facturation. Une réponse incorrecte est un problème, même si les bons mots figurent techniquement quelque part sur la page. Déplacez ou réécrivez l’explication selon le malentendu plutôt que d’ajouter automatiquement une note de plus.

Examinez aussi le tableau avec une valeur volontairement gênante : un nom de fonctionnalité long, une fonctionnalité indisponible ou une offre au prix négocié. Ce ne sont pas des exceptions de mise en page rares à reporter au développement. Elles déterminent si la structure comparative peut représenter l’offre réelle.

Dans OpenDesign, un aperçu HTML peut accompagner cette revue visuelle. Les commentaires peuvent désigner un groupe de prix trompeur ou une ligne de comparaison dont l’alignement se perd ; des modifications ciblées de texte ou de style peuvent affiner la présentation. Fournissez les faits validés des offres comme contexte de design. Vérifiez les calculs de facturation, l’éligibilité du compte et le comportement de paiement dans le parcours implémenté.

Avant de transmettre la page, comparez chaque prix et chaque limite visibles à la fiche de référence. Vérifiez les deux états de facturation, chaque action d’achat et la disposition étroite. Le tableau est prêt lorsqu’un lecteur sait expliquer correctement un choix adapté et ses conditions, y compris lorsque l’offre mise en avant n’est pas la bonne.