「きれいなWebサイトを作ったのに問い合わせが増えない」。そんなとき、デザインを少し素朴にすれば成果が出る、と考えるのは早計です。整ったデザインが必ず不信感を生むわけでも、手作り感が必ず信頼を生むわけでもありません。BtoBのサイトでは、顧客が必要な条件を発見し、理解し、比較し、問い合わせるまでの行動を支えられているかを確かめる必要があります。
このページの以前の本文には、洗練されたデザインは顧客を遠ざけ、素人っぽい見た目がむしろ有効だという主張がありました。しかし、特定条件を超えて一般化できる根拠を確認できません。そこで本記事は、サイトの見た目の優劣を先に決めず、読者の判断・使いやすさ・正確性を改善する観点へ組み替えています。
「信頼されるデザイン」の前に、読者が何をしたいか
検討を始めた担当者は、課題を解決できるかを知りたいかもしれません。情報システム部門は、連携条件やセキュリティを確認したいかもしれません。決裁者は費用と導入負担、購買担当者は契約条件を調べているかもしれません。必要な判断材料は一つではありません。
GOV.UK Service Manualの利用者ニーズに関するガイドは、設計者の想像を利用者の事実と混同せず、本人が何を達成したいのかを調べ続けるよう求めています。これは英国政府サービス向けの指針であり、BtoBサイトの売上改善を立証した研究ではありませんが、改善の出発点として参考になります。
- 導入前に判断したいことは、機能、費用、リスク、体制のどれか。
- その判断に必要な比較条件がページ内のどこにあるか。
- 技術者と決裁者が異なる情報へ迷わず進めるか。
- 詳細を確認する場合、どの公式資料や担当者へ進めるか。
- 対象外の読者が誤って申し込まないよう条件が明示されているか。
見た目の美しさと、使えるサイトは分けて評価する
Google検索セントラルのページエクスペリエンスの説明は、表示速度だけでなく、モバイルでの表示、邪魔な表示要素、主要コンテンツを区別できるかといった全体の使いやすさを考慮するよう勧めています。
ここから言えるのは「派手なデザインは検索順位を下げる」という単純な法則ではありません。Google自身、ページエクスペリエンスの要素を全部同じランキング要因とみなすべきでないと説明しています。美しさではなく、必要な情報を安全に利用できるかという複数の側面を確認します。
| 確認する箇所 | 読者に起き得る問題 | 確認方法の例 |
|---|---|---|
| 見出しと情報の順序 | 価格や制約が下の方に埋もれる | 利用者が目的の情報を探す場面を観察 |
| 比較表 | 機能は並ぶが前提条件が書かれていない | 対象プラン・費用・制約を並べて照合 |
| 可読性 | 文字が淡い、長文が詰まり読みにくい | コントラストと実機の表示を確認 |
| スマートフォン | 表が横へはみ出し選択できない | 実機幅で拡大・入力・リンクの動作を検査 |
| 問い合わせ導線 | 何を相談できるか、送信後どうなるか不明 | フォームと自動返信を実際にテスト |
| 信用に関する情報 | 実績の範囲や出典、運営者が分からない | 出典・対象条件・更新日・連絡先を点検 |
この表は当サイトによる実務の検査項目であり、いずれかを直せばコンバージョンが上がると実証した結果ではありません。
アクセシビリティは「好み」より優先して検証できる
W3CのWCAG 2.2のテキストコントラスト基準では、通常の文字は原則4.5:1以上、大きな文字は原則3:1以上のコントラスト比がレベルAAの基準です。ロゴや装飾などには例外があります。
『淡い文字の方が上品』という見た目の好みだけで、読者が読めない文字色を使うべきではありません。文字のサイズや背景との組み合わせをチェックし、スマートフォンや拡大表示でも利用できるか確認します。
ただし、コントラスト比を満たすだけでWCAGのすべての要件に適合するわけではありません。キーボード操作、リンク名、見出し構造、画像の代替テキスト、フォームのエラーメッセージなども対象です。W3CのWCAG全体案内から必要な達成基準を確認できます。
「本物らしさ」は粗いデザインで演出するものではない
実際の担当者が書いた説明や、顧客が許諾した導入事例には価値があります。しかし、手書きのような装飾や『社員のリアルな声』といった言葉だけで、情報の信頼性が証明されるわけではありません。
自社の実績を書く場合は、何を実施し、どこまで測定できたか、実際に誰が内容を承認したかを確認します。顧客の話を載せる場合はBtoB導入事例の根拠・掲載許諾ガイドのように、数値・コメント・画像の確認範囲をそろえる必要があります。
Googleのユーザー第一のコンテンツに関するガイドも、読者の役に立つ独自性と情報の正確さを重視しています。デザインを古く見せるのではなく、内容の根拠を閲覧者が見つけられるようにすることが先決です。
フォームの改善：入力を求める理由を明確にする
資料請求フォームで入力項目を増やすほど、有効な問い合わせが増えるとは限りません。一方、入力を減らしすぎると相談の内容を判断できないこともあります。必要な情報だけを、目的が伝わる形で尋ねる必要があります。
GOV.UKのフォーム設計ガイドは、各質問について『なぜ必要か』『回答を何に使うか』『どう正確さを確かめるか』を確認する考え方を紹介しています。BtoBの問い合わせでも、個人情報の取扱いと問い合わせの目的を明示し、無駄な情報収集を減らすために応用できます。
- フォーム送信前に、問い合わせの対象・対象外が分かるか。
- 個人情報の利用目的と、問い合わせ後の連絡方法が明示されているか。
- 必須項目・任意項目を区別し、理由のない質問を増やしていないか。
- 送信に失敗したとき、やり直し方法が分かるか。
- 送信できた場合、受信確認や次の流れを示せるか。
改善の検証は、閲覧の多さだけで決めない
デザインの改修が必要か考えるとき、PV、クリック、フォーム送信だけではなく、読者が必要な条件を理解できるかを観察します。利用者調査では、単に『このページが好きですか』と尋ねるより、価格の条件や連携の制限を探してもらう方が、説明が伝わったか検証できる場合があります。
仮説を作る際は、『読者が費用の見積方法を理解できないのではないか』という問題と、『比較表を先頭に置けばよい』という解決策を区別します。後者は実際に試して確認すべき仮説です。
長期のBtoB契約では、サイト上の一つのクリックを売上の因果効果とみなせません。GA4・Search Consoleの数値を誤読しないガイドで、計測できる事実と推測を分ける方法も確認できます。
実務で使う公開前・改修後チェック
- 公式の製品仕様、価格の条件、数値の根拠が更新されている。
- 初めて訪れた読者が、誰向けで何を提供するか理解できる。
- スマートフォン表示、文字、リンク、表、フォームを操作できる。
- 重要な条件・リスク・対象外が分かる場所に書かれている。
- 運営主体、連絡先、最終更新、必要な出典が確認できる。
- 変更前後で、同じ定義と期間のデータを記録できる。
参考資料と確認の限界
- GOV.UK：利用者のニーズを調べる。設計者の推測と実際のニーズを区別する公的指針。
- Google検索セントラル：ページエクスペリエンス。複数のUX要素を総合して考える公式資料。
- W3C：WCAG 2.2コントラスト基準。文字の可読性に関する達成基準。
- GOV.UK：フォームの質問構造。質問の必要性と使用目的を整理するための指針。
- Google検索セントラル：役に立つ情報と正確性。信頼できる内容を評価する考え方。
- 留保：本記事は特定サイトのユーザーテストやアクセス分析を実施した結果ではありません。例示した検査項目の効果は、実際の読者・端末・商品で検証する必要があります。
美しいデザインと、顧客が必要な情報を見つけやすいデザインは対立するものではありません。大切なのは、見た目の新旧で優劣を決めるのではなく、説明の正確さ、使いやすさ、閲覧者の選択を守ること。そこから、信頼に値するサイトを設計できます。