概要

技術に詳しくない上司は、ウェブサイトへのリクエストを投資ではなく経費と見なします。承認を得るには、ウェブサイトの修正をトライアルコンバージョン、チャーン、サポート負荷などの指標に結びついたビジネス上の決定として再構成する必要があります。この記事では、ビジネス上の問題を明確にする、依頼を金額の言語に変換する、何もしないことのコストを測定する、的を絞ったテストを実行する、計画を1ページにまとめる、「モダンにする」という反論を先回りする、という6つのステップの枠組みを紹介します。測定なしのリデザインは虚栄のプロジェクトであり、磨き上げではなくコンテンツと構造が成長を促進する理由を学べます。今日のうちにこれらのステップを使って、次のウェブサイトをめぐる議論を上司が「はい」と言える決定に変えましょう。

上司はウェブサイトを気にしていない。気にさせよう。

あなたの上司が、有料広告を打てるのに、なぜまたウェブサイトにスプリントを使うのかと尋ねたとします。あなたは何と答えますか？

「ホームページが古く見えるから」と答えたなら、すでに負けです。リデザインの依頼は意見のように聞こえます。ビジネスケースは決定のように聞こえます。その切り替えを行うための枠組みがここにあります。

ステップ1: デザインの依頼の背後にあるビジネス上の問題を特定する。

何を変えたいかを説明するのはやめましょう。現在のページがビジネスにどれだけのコストをもたらしているかを説明してください。

価格ページを見てください。無料トライアル中に人々が立ち止まる質問に答えていますか？価格ページの役割は、価値を伝え、プランを区別し、潜在的な顧客を購入の決定に導くことです。ページが価格を「お問い合わせ」フォームの背後に隠していたり、比較表を省略しているなら、それはデザイン上の欠陥ではなく、販売機会の損失です。直接言いましょう。「私たちの価格ページに訪れた人は、プランの違いがわからず、私たちの提案を聞くことなく去っていきます。」これは美的な好みではなく、ビジネス上のコストです。

同じ論理がFAQにも当てはまります。効果的なFAQセクションはサポート負荷を減らし、信頼を構築します。サポートチームが毎日同じ5つの質問に答えているなら、それは上司が二重に支払っている時間です。したがって、依頼は「FAQページを整理しましょう」ではなく、「見込み客が最初に目にする場所に回答を置くことでサポートチケットを減らしましょう」になります。

次に、機能紹介を変換します。スクリーンショット、GIF、短い動画などのビジュアルは、実際のユーザーエクスペリエンスを示すために存在します。機能の箇条書きの壁になっている場合、訪問者は自分がその製品を使っている姿を思い描けず、トライアルを延期したり、完全にスキップしたりします。それはまだ測定していなくても、ビジネス上の数字が付随するコンバージョンの問題です。

依頼を起草するときは、ビジネスコストを最初に書き、その後にデザイン変更を添付します。順序を逆にすると、要点を見失います。

ステップ2: 依頼を相手の言語に変換する。

あなたの上司は収益、チャーン、タイムトゥバリューで考えます。各ページをこれらの用語に変換してください。このマップを使って会話を準備しましょう。

変更したいもの	解決するビジネス上の問題
機能紹介のビジュアル	実際のユーザーエクスペリエンスを示し、トライアル登録者がコミットする前に価値を理解できるようにする
価格ページと比較表	訪問者を購入の決定に導き、「それだけの価値があるか」という反論に答える
APIドキュメント	開発者がより速く統合し、タイムトゥバリューを短縮し、サポート依頼を減らすのに役立つ
FAQセクション	よくある質問に答え、サポートチケットを減らし、ためらいの瞬間に信頼を築く

実際のミーティングでは、この表を1行か2行に絞りましょう。すべてを並べないでください。変更したいページを選び、そのビジネス上の成果を1文で伝えます。「価格ページがProプランがStarterプランの2倍の価値がある理由を説明していないので、読者は離脱する」というのは完全な論証です。テーブルは、あいまいにならないようにするための準備にすぎません。

ピッチを組み立てる前にパターンが必要なら、価格ページの改善はこれらのコンバージョンブロックから始まります。

ステップ3: 何もしないことのコストを正直に数値化する。

ほとんどの依頼に欠けているステップ、それが予測です。上司は「期待できる上昇率は？」と尋ねるでしょう。勝手なパーセンテージをでっち上げてはいけません。

代わりにこう言いましょう。「現在の数値は追跡したことがないのでわかりません。だからこそ、何かを変更する前に追跡を始めるべきです。ベースラインを設定し、テストを実行すれば、実際の数値が得られます。」これはその場ではあまり自信がなさそうに聞こえますが、全体的には反証できないので説得力があります。

具体的には、アナリティクスにイベントを追加して、価格ページを閲覧した後、同じセッション内で離脱したトライアルユーザーの数をカウントします。その数が多ければ、摩擦ポイントが見つかります。ドキュメントで既に回答されている質問に由来するサポートチケットの数を数えます。それが繰り返されるテーマなら、FAQの失敗を数値化したことになります。ピッチをする前にこれらの数字を書き留めておきましょう。

これは逆説的なポイントです。測定なしのリデザインは虚栄のプロジェクトです。「モダンに見せる」という承認を得るのは簡単ですが、その後、主観的な変更の成果を証明しようと苦労することになります。「まず実際の数値を知る必要がある」から始まる提案は、マーケターではなくマネージャーらしく見えます。それが目指すべき立場です。

ステップ4: リデザインではなく、的を絞ったテストを提案する。

ウェブサイト全体の作り直しを依頼してはいけません。高額で、時間がかかり、上司に「ノー」と言う理由を与えます。代わりに、1つのページと1つの変数を選びましょう。

どのページか？ 「何もしないことのコスト」のロジックを使います。最も測定可能な摩擦が発生するページです。次に、2週間の実験を提案します。そのページの1つの要素を変更し、ベースラインと比較し、そのまま採用するか元に戻します。それだけです。

自信は文書化されたパターンから生まれます。Stripe、GitHub、Twilioなどの企業の開発者が最も尊重するAPIドキュメントは、エンドポイントを列挙するだけでなく、使用方法を詳しく説明します。実際のインターフェースを示すスクリーンショットや短いGIFを使った機能紹介は、「実際に何を使うことになるのか」に答えるため、箇条書きに勝ります。価格FAQセクションが効果的なのは、反論が発生したまさにその瞬間にそれを解消するからです。これらは装飾的な選択ではなく、構造的なメカニズムです。

上司にテストを低リスクとして提示しましょう。「1つのページを変更し、2週間測定し、指標が動かなければ元に戻します。最悪の場合、2週間を失い、何が機能しないかを学びます。」それは簡単な「はい」です。

一度に2つのことを変更したいという衝動に抵抗してください。指標が動いた場合、どちらの変更が原因かわからなくなります。

テストするページがFAQの場合、コンバージョン資産としてのFAQページの分析が、何をテストすべきかを教えてくれます。

ステップ5: 計画を1ページにまとめる。

上司は40ページのデッキを読みませんし、詳細を隠す10スライドの要約も信頼しません。5つのブロックを持つ1ページを渡しましょう。

• 問題 — ページの背後にあるビジネスコストについての1文。
• 修正 — 正確な変更（1つのページ、1つの変数）。
• 指標 — 観察する数値（トライアルから有料への転換、サポートチケット、タイムトゥバリュー）。
• 期間 — 2週間、その後は意思決定ポイント。
• リスク — 指標が望ましくない方向に動いた場合は元に戻すため、低リスク。

この形式には2つの利点があります。正確さを強制され、承認が取り消し可能に感じられます。取り消し可能な決定は「はい」と言いやすくなります。予算項目は必要ありません。承認されたテストが必要です。

ページを送る前に、レビュー担当者を指名してください。反応が「何人かに見てもらう必要がある」というものなら、委員会地獄に陥っています。目標は1人の意思決定者と1つの期限です。上司が共有したい場合は、2週間の期間を失わないように、一度に全員が参加する単一のレビューミーティングをスケジュールしてください。

決定が得られたら、次の四半期に始まる開発サイクルを待ってはいけません。テストページの構築に1か月かかるべきではありません。仮説を試すためにページを数分で公開する必要があるなら、その速度は実験の一部です。

ステップ6: 「モダンにする」という反論を先回りする。

最も予測しやすい反論はこれです。「サイトが古く見えるだけだと思う。」その感情に反論してはいけません。それを認め、その後で本質に話を戻しましょう。

古いというのはビジネス上の問題ではありません。価値を説明する明確で平均的な見た目のページは、メッセージを埋もれさせる豪華なページよりも優れたコンバージョンを達成します。磨き上げは信頼のシグナルであり、コンバージョン戦略ではありません。SaaSウェブサイトに関する調査はこれを支持しています。機能紹介は、単に見栄えがするときではなく、ユーザーエクスペリエンスを実証するときに勝ちます。HubSpot、Slack、Zendeskなどの企業の例として挙げられるFAQページは、クロームではなく、整理されたコンテンツと簡潔な回答によって成功しています。

したがって、リデザインに同意しますが、1つの条件を付けましょう。「リデザインは、現在のサイトよりも明確に[specific value proposition]を伝えるべきです。」新しいデザインが製品の価値をより明確に表現していなければ、どれだけモダンに見えても失敗です。これは好みの議論を測定可能な目標に変えます。

ビジュアルのリフレッシュから収益の数字を約束したいという誘惑に抵抗してください。テストを実行するまで、それを予測できる立場にありません。

議論全体を収益に結び付けておきましょう。一貫性のあるSaaSウェブサイトを構築するための再現可能なシステムは、すべてのページをその目標に合わせる方法を示しており、ページごとにこの戦いを繰り返さなくて済みます。

結論

ウェブサイトの変更をデザイン上の意見として提案するのはやめましょう。指標、テスト、期限を備えたビジネス上の決定として提案してください。訪問者が滞在するか去るかを決めるページ、つまり価格、FAQ、APIドキュメント、機能紹介から始めましょう。何かを変更する前にベースラインを測定します。1つのページを2週間テストします。計画を1枚のページにまとめます。そして上司が「モダンにして」と言ったら、「明確にしてください」と言い換えましょう。

次にその質問が来たとき、「またウェブサイトに触っているのか？」——あなたは固まらないでしょう。すでに数字、テスト、1ページの計画が目の前にあるからです。それが、許可を求めることとビジネスケースを実行することの違いです。