トラフィックが少ない状態でSaaSのランディングページのメッセージをテストするには、暫定的に定めた1つのオーディエンスに当てはまる人に現在のページを見せ、補足なしでの理解を記録してから、ページ全体を見てもらい反論を聞き出します。生の回答を残し、次に行う具体的な変更を1つ選びます。この定性調査は誤解を明らかにできますが、コンバージョンの向上を立証したり、A/Bテストの勝者を決めたりすることはできません。
オーディエンスと不確実な点を1つずつ選ぶ
募集を始める前に、想定する読み手、その人が現在行っているタスク、そして理解してほしいことを書き出します。クライアント引き継ぎツールであれば、不確実な点は「アカウントマネージャーが、このツールは営業リードを集めるものではなく、担当の引き継ぎを調整するものだと理解できるか」かもしれません。
ページのバージョン、または日付入りのスクリーンショットを固定します。1回のラウンドでは同じ種類のデバイスと同じ指示を使い、違いがページによるものか手順によるものかを見分けられるようにします。調べるのが第一印象なのか、説明全体なのか、それとも期待される次のアクションなのかを決め、それぞれの観察を分けて記録します。
参加者スクリーナーをコピーする
これらの質問は、製品を見せる前に尋ねます。適切な紹介、既存の関係、または調査依頼の投稿が認められているコミュニティを通じて募集します。所要時間を伝え、断れるようにしておきます。通常の通話と自分のメモだけで実施でき、このプロトコルにテスト用ツールのアカウントは必要ありません。
- あなたの役割は何ですか。[中立的なワークフローの説明] のうち、ご自身で担当しているのはどの部分ですか。
- 最後にそのタスクを行ったのはいつですか。そのときの状況と使ったツールを教えてください。
- ほかに誰が関わっていますか。チームがツールを変えるかどうかは誰が決めますか。
- この製品を以前に見たこと、またはそのページの制作に関わったことはありますか。
- ページを確認していただき、回答についてのメモを保管してもよろしいですか。録音や個人を特定できる資料の共有を行う前には、別途同意を得てください。
誘導せずに短時間表示のスクリプトを実施する
- 想定するビューポートでページを用意します。「私が確認しているのはページであって、あなたをテストしているわけではありません。ページが何を伝えていると思うか話してください。わかりにくいところがあっても問題ありません」と伝えます。意図したメリットは説明しません。
- ファーストビューを短時間表示してから隠します。5秒は第一印象を確かめる実用的な形式の1つですが、普遍的な合格基準ではありません。実際の表示時間と中断を記録してください。時間制限のある提示が参加者にとって難しい場合は、時間制限なしの条件を別に設けます。
- 「この製品は何をするものだと思いますか」と尋ねます。追加の説明をする前に、その回答を記録しておきます。
- 「誰が、どんなタスクのために使うと思いますか」と尋ね、続けて「そう思ったのは、何を覚えているからですか」と聞きます。
- 「次に何が起こると思いますか（もしあれば）」と尋ねます。こちらが望む回答の選択肢を示すのではなく、迷いは迷いとしてそのまま記録します。
ページ全体を見せて理由を掘り下げる
- 参加者に自分のペースでページを見てもらいます。「さらに読んでみて、今ならどう説明しますか」と尋ねます。この回答は最初の言い換えとは分けて記録します。
- 「このページのどの部分が、前回そのタスクを行ったときの状況とつながりますか（もしあれば）」と尋ね、続けて「チームの仕事の進め方と合わない点はどこですか」と聞きます。
- 「試すかどうかを決める前に、何を知る必要がありますか」と尋ねます。ページを擁護するのではなく、「なぜそう思いますか」と深掘りします。
- 「次のステップに進みたいとしたら、どこに行きますか。そこで何があると思いますか」と尋ねます。アカウント登録や購入を求めずに、参加者が示した操作要素を観察します。
- 最後に、まだわかりにくい点を尋ねます。意図したメッセージを説明するのは参加者にお礼を伝えた後にし、その説明が記録済みの回答に影響しないようにします。
セッション記録と解釈表をコピーする
- 参加者コード：[…]、役割と最近の関連ワークフロー：[…]、スクリーナー結果：[…]。
- ページのバージョン／日付：[…]、ビューポート：[…]、表示時間または時間制限なしの条件：[…]、中断：[…]。
- 補足なしでの言い換え（発言どおり）：[…]、想定されたユーザー／タスク：[…]、覚えていた根拠：[…]。
- ページ全体を見た後の言い換え（発言どおり）：[…]、現在の代替手段：[…]、反論と言及されたセクション：[…]。
- 期待される次のステップ：[…]、モデレーターによる説明（あれば）：[…]、矛盾する回答：[…]。
- 解釈：[…]、裏付けとなる発言：[…]、別の説明の可能性：[…]、次に提案する確認：[…]。
読み手が別の製品やタスクを挙げ、あいまいな言い回しを指摘します。具体的なタスクの説明や例を試し、その修正版をテストします。見慣れない用語やテストの設定そのものが混乱の原因になっていないかも確認します。
読み手は製品を正確に説明できるものの、最近の業務にその課題が含まれていません。全員向けに約束を書き直す前に、募集方法と暫定セグメントを見直します。
読み手は製品を理解し、その課題も経験していますが、乗り換える理由が見いだせないか、必要な裏付けが足りません。導入の手間や答えの出ていないワークフロー上の疑問など、具体的な反論を調べます。理解しただけでは納得したことにはなりません。
価値は理解されていますが、読み手はデモが開くと思っているのに、ボタンを押すと登録フォームが開きます。ボタンのラベルと遷移先への期待を、別の変更として確認します。
回答が食い違っている、モデレーターが回答を誘導した、または最近の関連ワークフローが確認できていない状態です。その限界を記録し、的を絞ったラウンドをもう一度行います。両立しないケースを平均して、勝ちを示すスコアにしてはいけません。
架空の結果：見出しは維持し、セグメントを見直す
「アカウントの担当が替わるときも、クライアントの担当をはっきりさせる」という見出しを持つ、架空の引き継ぎツールを考えてみます。この架空のラウンドでは、2人の個人コンサルタントがそれぞれ独立に、これをアカウント移管のチェックリストだと説明します。2人とも、クライアントを1人で管理しており、最近アカウントを移管したことはないと話します。
これらの観察は、この2回のセッションでは理解できていたことを裏付けます。同時に、スクリーナーが一般的なクライアント管理の経験を受け入れ、実際に担当の引き継ぎを行ったかどうかを確認していなかったことも明らかにしています。次の判断は、最近、アクティブなクライアントを移管したアカウントマネージャーを募集し、同じページで再度テストすることです。見出しを書き直したり、コンバージョンの改善を報告したりするのは時期尚早です。
別の架空のリハーサルでは、事前に創業者のいつもの売り文句を聞いていた友人が、それをそのまま繰り返します。この回答は補足なしの調査から除外します。生成されたAIペルソナが「買う」と答えても、それは参加者でも購買シグナルでもありません。
修正を選び、まだわからないことを残しておく
判断カードを1枚書きます。ページのバージョン → 観察された誤解または反論 → 裏付けとなる生の回答 → 提案する変更 → 受け入れチェック → 未解決の問い。コピーを変更した場合は、可能であれば条件に合う新しい読み手で確認します。以前の参加者はあなたの説明を覚えている可能性があります。
ページがわかりやすくなっても、見込みのある訪問、完了したアクション、製品の価値については別の証拠が必要です。後でA/Bテストを行う場合は、開始前に成果指標、必要な感度（検出したい最小の差など）、サンプル計画を決めておきます。最初に優勢に見えた時点で止めたり、数件のインタビューから向上を推測したりしてはいけません。
出典と次のプロダクトの議論
現在のURL、共有してよいメモ、選んだ変更をSoloopに持ち込んで議論してください。その後、サポートされているBuildタスクで、受け入れ基準と承認のもとで具体的な修正を実装できます。参加者の募集と調査はご自身で行ってください。本記事は、Soloopをテストパネルやコンバージョン予測サービスとして説明するものではありません。
Lyssnaは、公式のホームページメッセージテンプレートで、短時間の第一印象の表示とページ全体についての質問を組み合わせています。本記事のスクリーナー、判断記録、架空のオーディエンスのずれの例は、編集部によるオリジナルの資料です。
Lyssna：How to test home page messaging