分かりやすい料金表をデザインする方法

役立つ料金表なら、計算機や別のブラウザータブを開かずに、三つの問いに答えられます。自分の仕事に合うプランはどれか。実際にいくら払うのか。選んだら次に何が起こるのか。

簡単そうですが、本物の製品情報をレイアウトに入れると複雑になります。あるプランには編集者5人が含まれ、別のプランは編集者ごとの料金。年払いは月額換算で表示され、最も重要な機能は十二個の同じチェックマークの下に埋もれています。カードは洗練されていても、選ぶのは難しいままです。

具体例には、架空のコラボレーションサービスFieldnoteを使います。

カードを描く前に、選ぶ内容を定める

訪問者にしてほしい判断を、一文にします。Fieldnoteなら、個人のリサーチャー、小規模のプロジェクトチーム、一元管理が必要な組織に合うワークスペースのプランを選ぶことです。

これらは運用上のニーズの違いです。どの料金ページも三列にする、と決めるよりよい出発点になります。有料パッケージが一つなら、比較より料金の説明が必要かもしれません。別々の製品を扱うサービスなら、最初に製品選択が必要かもしれません。本質的に異なる購入を隣の列に並べると、代わり合うものではないのに、そう見せてしまいます。

どの事実が選択を変えるのかを、プロダクトの責任者に聞きます。この例では、稼働中のプロジェクト数、含まれる編集者数、ゲストアクセス、管理機能が重要です。ストレージも異なりますが、想定する対象者の最初の選択を左右する可能性は高くありません。この区別でページの順序が決まります。まず適合を伝え、次に確認に必要な詳細を示します。

デザインとは別に、簡単な事実一覧を持ちます。プラン名、対象者、課金単位、含まれる数量、上限、アップグレードの条件、購入の手順を記録します。未決なら未決と記します。魅力的なモックアップの中で、抜けている販売上のルールをうっかり決めてしまうのは、とくに避けたいことです。

事実一覧は、修正の不整合も防ぎます。編集者の含まれる人数を変えたら、概要、比較表の行、計算機、FAQをすべて見直す必要があるかもしれません。同じ数字が偶然入った別々の文章ではなく、一つの事実の異なる表示として扱います。

料金表のデザイン：まず候補を絞り、それから比較する

プランのカードと機能比較表の仕事は違います。カードは候補を絞るためにあり、比較表は候補が具体的な要件を満たすか確かめるためにあります。すべての詳細をカードに入れようとすると、違いを探しにくい長い列になります。

Figmaの料金ページのガイドでも、簡潔なプラン表示と、詳細な比較表が区別され、価格の近くで課金単位を明示することが勧められています。ここでの構造の基礎になる考え方です。Figmaの料金ページのガイド。

Fieldnoteなら、Soloは個人でのプロジェクトを説明してから、価格、稼働中のプロジェクト上限、ゲストアクセスを示せます。Teamは共同リサーチを説明し、価格、含まれる編集者数、共有プロジェクトの容量を示します。Organizationは一元管理と、営業担当を通じた購入方法を説明できます。見積もりが必要な販売モデルなら、無理に架空の公開価格を最後のカードに入れる必要はありません。

値が異なっても、情報の順序は揃えます。あるカードはボタンの下に請求条件を置き、別のカードは価格の横に置くと、関係を探す必要が生じます。整列は説明の役目を果たします。同じ位置なら、同じ種類の情報だと分かります。

GitHubの料金ページを、二段階で読む

GitHubの料金ページは、概要と詳細比較を分ける、実際の参考例です。プランの領域で選択肢と購入方法を示し、その下の機能比較では違う細かさの情報を提供します。画像の価格はページ構造を説明するためのもので、現在の条件は実際のページで確認してください。

二つの領域には、違う問いを向けます。概要では、自分のチームに合いそうな選択肢を見分けられるか。比較表では、その選択肢を除外する決め手となる一つの要件を確かめられるか。導入のカードと調達時の確認には、同じ情報密度は必要ありません。比較表の全行を載せたカードは、もはや概要ではなくなります。

購入しそうな人に、適切なプランを選び、支払いの約束を説明してもらいます。その答えで、レイアウトが何を伝えているかを試せます。

読者が実際に選ぶ請求額を計算する

席数ごとに課金する別の例として、架空のSeatMeterを考えます。表示は編集者1人あたり月額12ドル、年払い、最低5人です。3人のチームだから毎月36ドルになるとは限りません。この条件なら、最低の年間支払い額は12ドル×5人×12か月＝720ドルです。

個々の数字は正しくても、料金のデザインはここで失敗しがちです。月額換算は記憶に残り、実際の支払いはほとんど目に入らない優先順位になっています。今日いくら請求されると思うかを説明してもらいましょう。請求額ではなく単価を答えるなら、単価をさらに大きくしても誤解は解消しません。

割引バッジで比較の基準を隠さないようにします。年払いが月払い12回に対して20%安いなら、どの月額を基準にしたかを示します。初回期間だけのキャンペーンなら、その条件を割引後の金額の近くに置きます。一時的な特典に恒久的に見えるバッジを付けると、脚注では取り消せない期待が生じます。

含まれる容量についても同じです。**「編集者5人分を含む」と「有料の編集者は最低5人」**は、開始時の人数が同じでも、販売上のルールは異なります。実際のルールを事実一覧に書き、カード、比較表、決済への引き継ぎで意味を揃えます。

ワークスペース単位では、計算が違う

金額、通貨、課金単位、支払い条件を一緒に見せます。 年間契約を月額換算で表示するなら、年額の請求総額も同じ視覚的なまとまりに入れます。

Fieldnote Teamの月払いが、ワークスペースあたり月額30ドルだとします。ワークスペース単位の年払いは、年額288ドルで、月額換算24ドルです。分かりやすい年払いのカードなら、月額換算を主な数字にし、そのすぐ後に、年に288ドルを請求すると説明できます。24ドルを12回に分けて払えるのかを、推測させてはいけません。

ワークスペース料金と席単価の違いにも、同じ注意が必要です。6人のチームが実際には6倍払うなら、「月額24ドル」だけでは不十分です。決まった編集者数を含むのか、編集者一人ひとりにかかるのか、最低数量があるのかを示します。数量の前提は、離れたツールチップではなく、価格と同じ領域に置きます。

従量課金なら、計算機を付ける前に境界を説明します。基準が見えない計算機は、不確かな料金を正確そうに見せることがあります。何の利用が含まれ、何を超えると追加請求になり、任意の項目を見積もりに含むかを示します。計算できる安定した単価がないなら、代わりに営業担当に必要な情報を説明します。

一つの比較行で複数の単位を混ぜてはいけません。「10」と「無制限」は、何を、どの期間で数えるかが分からなければ曖昧です。「稼働中のプロジェクト数」と「月間に作成したプロジェクト数」は違います。数字が同じでも、購入の判断は変わります。

請求間隔の切り替えは、契約条件の変更として扱う

月払いと年払いを切り替えたら、影響する事実をすべて同時に更新します。大きな数字にアニメーションを付けるだけではありません。年額、割引の説明、支払い条件、購入操作の移動先が、選択中の状態と一致する必要があります。

Fieldnoteの例では、月払いを12か月続けると360ドル、年払いは288ドルです。差は72ドルで、月払いの合計の20%です。節約額を表示するなら、その基準を明確にします。割引後の年額を、別のキャンペーン料金と比べれば、違う話になります。

選択中の状態とラベルは、曖昧であってはいけません。小さなスイッチの両側に言葉があると、左のラベルが今の値なのか、選べる別の値なのか分からないことがあります。選択が目に見えるセグメント式の操作要素は、プロトタイプで説明しやすい場合があります。どんな形でも、キーボードで使えて、色だけに依存せず選択状態が分かる必要があります。

ページの下にあるプランを見ながら切り替えてみます。どの請求間隔か分かるでしょうか。長い比較表の近くに請求間隔のラベルを繰り返すほうが、はるか上へ消えた操作要素より有用かもしれません。価格が文脈を失うのを防ぐ繰り返しには、理由があります。

変えないものも決めます。実際の内容が変わらないなら、請求頻度を変えただけで、プランの順序や機能の上限を動かすべきではありません。予想外の並べ替えは二つの状態を比較しにくくし、サービス自体が目の前で変わったように見せます。

正しく比較できる行を作る

一つの行は一つの問いに答え、すべてのプランに答えを用意します。「プロジェクト数」なら数字です。「ゲストアクセス」なら「含む」「含まない」かもしれません。一方、あるプランはメールサポート、別のプランは担当者付きなら、「サポート」には説明が必要です。チェックマークだけでは、この違いは表せません。

行内では、単位と具体性の水準を揃えます。Soloに「稼働中のプロジェクト3件」とあるのに、Teamを「成長するための十分な余裕」にしてはいけません。後者は、表が果たすべき比較を避けています。販促表現は周辺の説明に置き、セルには実際の上限を書きます。

ないことと、不明なことを区別します。ダッシュは、非対応、該当しない、非公開、ゼロのどれかかもしれません。違いが重要なら言葉で明示します。記号を使うなら、意味を明確にし、支援技術にも伝わるようにします。空のセルが制限なのか掲載ミスなのか、買う人に推測させてはいけません。

機能名も揃えます。同じ機能を最初のプランで「共有フォルダー」、次で「共同作業スペース」と呼ぶと、存在しないアップグレードに見えるかもしれません。本当に変わるなら、人数、履歴の期間、権限、サービス上の約束など、何が変わるかを説明します。

行は、認識しやすい問いに沿ってまとめます。Fieldnoteなら、プロジェクトでの作業、コラボレーション、管理の区分が考えられます。目的は答えを見つける助けであって、社内の担当部署の再現ではありません。買う人がアクセスの共有を考えているなら、裏側で複数の開発チームが担当していても、たどり方は明確にします。

「前のプランのすべてを含む」には注意します。カードは短くなりますが、上位プランの理解に別の場所を読む必要が生じます。短い概要なら許容できる場合もありますが、比較表では、実際の値を繰り返すほうが、各行を独立して比べられて便利です。

理由のあるおすすめを示す

強調したプランには、何に合うかを説明します。「複数のプロジェクトでリサーチを共有するチーム向け」なら、Fieldnote Teamを考える理由になります。「最もお得」は、基準を明かさずに判断を受け入れるよう求めています。「最も人気」は事実の主張なので根拠が必要で、おすすめの代わりの装飾にしてはいけません。

他の選択肢の読みやすさを保ちながら、強調で出発点を示します。少し強い枠、小さなラベル、控えめな面の変化でも可能です。中央のカードを大きくしすぎて周囲の条件が追いにくくなるのは、適切な取捨選択とはいえません。強調された案も、ほかと比較する必要があります。

強調を外して確認します。それだけで内容が理解不能になるなら、強調に説明の役割を任せすぎています。色で優先順位を加える前に、プラン名、対象者の説明、見える違いで、妥当な選択ができるべきです。

狭い画面でも、違いを隠さない

プランのカードを縦に積むのは簡単でも、比較を保つのは難しいことです。一つのプランが一画面を占めると、最初のプランに機能があったかを覚える作業が増えます。すっきりした縦配置なら簡単に比較できる、と考えないようにします。

少数のプランなら、縦積みでも機能の順序を揃えます。長い比較表なら、二つのプランを選べる狭幅用の比較や、位置関係が分かる横スクロールの表を検討します。主に一つのプランを読むのか、特定の複数の値を比べるのかで、適した形は変わります。

アコーディオンは最初の長さを減らせますが、情報も隠します。重要な制限と請求条件は閉じた部分の外に置きます。ゲストアクセスを含むプランを知るために全部を開くなら、同じ手間を、より多くの操作に分散しただけです。

実際のデータテーブルでは、構造的な関係を保ちます。W3Cのテーブルのチュートリアルは、見出しセルとデータセルを関連付け、支援技術からも関係を利用できるようにする方法を説明しています。文字を見た目だけで格子状に並べても、同等の実装にはなりません。W3Cのアクセシブルなテーブルのチュートリアル。

狭い画面で、編集者6人と稼働中のプロジェクト20件に対応する最安の案を探す、という比較を試します。この仮の条件で、選択に必要な情報が残るかが分かります。画面幅に収まるかだけを確かめても、答えは得られません。

操作名を、次の手順に合わせる

ボタンは、直後に実際にできることを説明します。トライアル開始、無料ワークスペース作成、有料契約選択、営業への問い合わせは別々の手順です。全部を「始める」にするとボタンの行は揃いますが、操作は曖昧です。

重要な条件は、関係する操作の近くに置きます。トライアルに支払い方法が必要なら、進む前に伝えます。組織向けプランが相談から始まるなら、すぐ決済へ進むようなボタン名を避けます。目的は正確な期待を作ることで、購入の全工程をカードに詰めることではありません。

既存の契約者も考えます。一般公開の料金表から重複した新規登録へ送ってしまう場合があります。最終的な実装では、現在のプランの表示や、アカウント設定への経路が必要かもしれません。プロトタイプにアカウントのロジックを実装しなくても、初めての訪問者だけで評価しないよう、この状態を記録します。

選べないものをすべて無効なボタンで表すのも避けます。利用資格がアカウントの条件によるなら、その条件を説明します。説明のない無効な操作要素では、制限、一時的なエラー、意図したルールのどれなのか分かりません。

画像のGitHubのカードは、この違いを具体的に示しています。Teamには「Continue with Team」があり、Enterpriseにはトライアルと営業への連絡の両方があります。後者はプランの二つの機能ではなく、一つのプランに入る二つの経路です。レビューでは各経路をたどり、次にどんな情報が必要かを確認します。ボタンの色を揃えて視覚的なリズムを保ちながら、ラベルでは次の手順を具体的にできます。

選ぶタスクを使って、案をレビューする

各レビュー担当に答える問いがあると、見た目のレビューが有用になります。一人に個人利用、別の人に成長中のチームのシナリオを渡します。プランを選び、根拠になった事実を説明してもらいます。その考え方から、自由に感想を求めるだけでは見逃す曖昧さが見えてきます。

Fieldnoteなら、二つのプロジェクトと複数のゲストを持つリサーチャーの例、編集者6人の例、組織全体の管理が必要な例を使えます。強調したプランが不適切になるシナリオも含めます。そうでなければ、比較で別の結論を出せるかではなく、強調が効くかだけの確認になります。

続いて、すぐ請求される額と、支払いの約束を述べてもらいます。正しい言葉がどこかに存在していても、答えが誤っていれば問題です。機械的に脚注を増やさず、誤解に応じて説明の位置や文言を変えます。

長い機能名、使えない機能、交渉で決まる価格など、意図的に扱いにくい値も確認します。開発まで後回しにしてよい珍しい例外ではありません。比較の構造が本当の提供条件を表せるかを左右します。

OpenDesignのHTMLプレビューは、この見た目の確認を助けます。誤解を招く価格のまとまりや、整列が崩れる比較行にコメントし、対象を絞って文章やスタイルを直せます。承認済みのプラン情報を文脈として渡しましょう。請求計算、アカウントの利用資格、決済の動作は、実装したフローで確かめます。

引き渡す前に、表示したすべての価格と制限を事実一覧と照らします。両方の請求間隔、すべての購入操作、狭いレイアウトを確認します。強調したプランが正解ではない場合も含め、読者が適切な選択と条件を正確に説明できるとき、料金表は準備ができています。