LP公開前のユーザーテスト｜迷い・誤解を見つける手順と公開事例

LPのデザインが完成すると、社内では「きれいになった」「ボタンをもっと目立たせたい」といった意見が集まります。しかし、公開前に確かめたいのは、初めて訪れた人がサービスを理解し、自分に合うかを判断し、必要な行動を取れるかです。社内で説明を聞きながら見るページと、検索や広告から一人で訪れるページでは、前提が違います。

その違いを見つける方法がユーザーテストです。本記事では、LPの発注担当者や中小企業の経営者に向けて、公開前のテストを準備し、観察結果を修正指示に変えるまでを説明します。英国政府の公式ガイドと公開された改善例を参照しつつ、企業のLPに応用する際の手順を整理しました。本文中の設備点検サービスは手順を説明するための架空例であり、実際の顧客成果ではありません。

LPのユーザーテストでは何を確かめるのか

好き嫌いの評価から、判断できるかの確認へ

ユーザーテストでは、対象に近い人に具体的な目的を持ってページを利用してもらい、その行動を観察します。「このデザインは好きですか」だけでは、色や写真の印象に話が寄りやすくなります。「今の状況で依頼できそうか調べてください」と頼むと、対応地域を探す、費用の条件を読む、申し込み後の流れを確かめるといった判断過程が見えてきます。

この考え方は、実際の利用者や利用する可能性のある人の操作を観察する、GOV.UKの進行役のいるユーザビリティテストの公式ガイドに基づきます。LPでは特に「誰向けのサービスか」「何が提供されるか」「どの条件なら相談できるか」「次に何が起こるか」を、説明を添えずに理解できるかが重要な確認点になります。

アクセス解析やA/Bテストとは答える疑問が異なる

アクセス解析は、どのページから来たか、どの行動がどれだけ発生したかを調べる手がかりになります。一方、公開前は十分な訪問データがありません。また、途中で離れたという数字だけでは、内容が合わなかったのか、条件を見つけられなかったのか、操作できなかったのかまでは確定しません。行動を見ながら理由を確かめる調査には、数字を読むだけでは立てにくい仮説を得る役割があります。

少人数のテストで「この案なら問い合わせが何％増える」と予測することもできません。A/Bテストは公開後に条件をそろえて案を比較する別の方法です。まず明らかな誤解や操作の障壁を取り除き、公開後に実際の利用状況を確かめる流れを考えましょう。数値での比較はLPのA/Bテストの進め方で扱い、ここでは公開前の理解と行動に焦点を当てます。

実施前に、誰のどんな疑問を調べるか決める

検証したい疑問を三つ程度に絞って共有する

最初に用意するのは長い質問票ではなく、判断したいことを短く書いたメモです。例えば「初めて依頼する担当者が対応可能な設備を判断できるか」「見積もりに必要な材料が分かるか」「相談しただけで契約になると思っていないか」の三つです。三つは本記事での進行例であり、決まった標準ではありません。一度に確認する範囲を絞ると、観察結果をどの修正につなげるかが明確になります。

疑問には、社内で想定している根拠も添えます。営業担当が説明に時間を使っている条件、問い合わせで繰り返し確認される事項、今回新しく設けた申込方法などが候補です。ただし「営業が不安だから必ず問題がある」とは決めません。問題が起きなかった場合も記録できるよう、「不安を証明する調査」ではなく「現状を確かめる調査」にしておきます。

役職や年齢だけで参加者をそろえない

設備点検の依頼先を探す人でも、初めて任された総務担当者と、毎年複数社の見積もりを比べる施設責任者では、必要な説明が違います。参加者の条件は、業種や役職に加えて、依頼経験、現在の困りごと、社内での決裁への関わり、利用する端末から考えます。実際には上司が決めるのに、担当者がその場で契約する設定を与えると、現実とは違う行動を観察することになります。

社員や親しい知人は、準備した手順が動くかを確かめる予行演習には向いています。しかし、会社名やサービスを知っている人だけの結果を、初めての訪問者全体に広げるのは無理があります。誰に協力してもらえたか、誰の状況は確認できていないかを報告に残しましょう。集めやすさのために条件を変えた場合も、後から分かるようにしておきます。

人数より、次の修正判断に必要な組み合わせを考える

決まった人数に達すれば十分、という扱いは避けます。初回相談と継続契約、スマートフォンと業務用PCなど、行動が大きく違う条件を混ぜたまま少数の合計だけを見ても、どの人の問題なのかが分からなくなります。まず重要な利用状況を一つ選び、小さく実施して、未確認の疑問や条件を次の回に回す方が、修正の理由を説明しやすくなります。

例えば初回は「初めて依頼先を探す担当者が、スマートフォンで相談条件を確認する」場面に限定します。そこで見つかった誤解を直した後に、PCで社内比較資料を作る場面を確認する計画です。この順番は対象事業に合わせる必要があります。重要顧客が業務用PC中心なら順番を逆にします。想像した標準ユーザー一人ですべてを代表させないことが大切です。

現実に近く、答えを教えない課題をつくる

「ボタンを押す」ではなく、達成したい目的を渡す

課題文に「ページ下部の無料相談ボタンを押してください」と書くと、場所も名称も教えてしまいます。これでは、ボタンを発見できるか、押した結果を理解しているかを十分に確かめられません。GOV.UKの前掲ガイドも、課題に明確で現実的な目的を持たせ、答えや操作方法をほのめかさないことを勧めています。指示を読んだだけで答えが分かる箇所がないか、事前に見直します。

架空の設備点検LPなら、「来月、店舗の設備点検を予定しています。担当として依頼先の候補を探してください。相談できそうかを判断し、次に進むならどこまで進めるか試してください」と設定できます。その人の立場ではまだ分からない予算や設備型番を、無理に知っている前提にはしません。「条件が分からず、いったん上司に確認する」という行動も、重要な観察結果です。

調べる、比較する、申し込むを分けて観察する

一つの長い課題だけで進めると、最初にサービス内容を誤解したまま、後の操作を終えてしまう場合があります。途中で「ここまでで、どんなサービスだと思いましたか」「依頼を考えるうえで、まだ分からないことはありますか」と確認する区切りを設けると、理解の変化を追えます。正しい説明を教えるための質問ではなく、その時点でどう理解したかを聞く質問にします。

比較の場面では「上司に候補として伝えるとしたら、何を説明しますか」と聞く方法もあります。ページのコピーをそのまま読むか、自分の言葉で対象・条件・不明点を整理できるかで、伝わり方が違います。競合を同時に見せる場合は、提示順や情報量の違いが判断に影響します。初回から盛り込みすぎず、自社LP単体の確認と、複数候補の比較を別の目的として扱います。

開始地点と終了地点を決めておく

広告の文章に「翌日対応」と書かれているのに、LPだけを見せてテストすると、広告から引き継がれる期待が消えてしまいます。実際に使う広告案や検索結果に近い入口が決まっているなら、それも含めて確認します。まだ入口が未定なら、その制限を記録します。最初にサービスを詳しく口頭説明すると、LPに説明が足りないことを見落とすので注意が必要です。

終了地点も明確にします。画面上で申し込みを完了するところまで見るのか、入力内容の確認までなのかで、用意する環境が変わります。営業通知が届く本番フォームに架空の申し込みを流すことを前提にせず、テスト専用の受け口や送信しない試作を準備します。作動しない箇所がある場合は、必要な場面でその制約を説明し、利用者の失敗と混同しないようにします。

公開された改善例から、質問文の役割を学ぶ

GOV.UKの有権者登録で起きた「第二の住所」の迷い

GOV.UKの質問の設計に関する公式ガイドは、有権者登録サービスの初期版で、別の住所にも住んでいるかという質問に、利用者が「はい」「いいえ」を選びにくかった例を紹介しています。第二の住所に何が含まれるのかが分からなかったためです。そこで、二つの住まいで暮らしている場合と、学生が自宅と学期中の住所を持つ場合を具体的な選択肢として示したところ、回答しやすくなったと報告されています。

ここで参照できる結果は、公式ガイドに記載された回答のしやすさの改善です。問い合わせ率や売上の変化が示された事例ではなく、企業向けLPと同じ条件でもありません。自社に応用する際は、「簡単な二択でも、利用者が言葉の範囲を決められないと答えられない」という観点を使います。選択肢を増やすこと自体を正解とするのではなく、何が判断を止めているかを確かめます。

企業のLPでは、社内用語を判断可能な条件へ変える

設備点検LPの架空例で「定期保守をご希望ですか」と聞いても、初めての担当者には、一回の点検が定期保守に入るのか分からないかもしれません。もし観察でその迷いが確認できたなら、「今回の点検について相談したい」「継続的な点検の契約について相談したい」「まだ決まっていない」といった案を検討できます。実際の受付で処理できる選択肢であることも、営業担当に確認します。

同様に「概算」「現地調査」「対応可能」といった言葉にも、会社側と利用者側で幅があります。概算には何が含まれるか、現地調査を申し込むと費用がかかるか、対象地域内なら必ず受けられるか。質問が多いときは、単純に説明文を増やす前に、判断の単位が合っているかを見ます。条件を具体化した案と元の案を同じ課題で確かめれば、見た目の好みだけで議論せずに済みます。

試作と当日の進め方を整える

確かめたいことに合わせて試作の精度を選ぶ

文章の順番やサービスの理解を確かめたいなら、初期の構成案でも学べることがあります。一方、メニューの操作、入力時のエラー、スマートフォンでの固定ボタンの重なりは、画像だけのデザイン案では判断しにくくなります。GOV.UKのプロトタイピングの説明も、スケッチからコードで作ったものまで、段階に応じた試作を扱っています。完成度を高めること自体ではなく、調べたい疑問に答えられることを基準にします。

試作の省略箇所は一覧にして進行役と共有します。「このリンクは未実装」「料金表は仮の値」「送信後のメールは再現しない」といった項目です。仮の値で価格への納得感まで評価しない、押せないリンクで導線の良し悪しを判定しないなど、結果を使える範囲も決めます。完成した画面のように見えても動かない部分がある試作では、特に必要な準備です。

進行役は説明したい気持ちをいったん保留する

自分で制作したページを見る人が迷っていると、「そこは下に書いてあります」と助けたくなります。しかし、その一言で、本来は見つけられなかったという情報が失われます。進行役は、沈黙を急いで埋めず、まずどこを見ているかを観察します。確認するなら「今、何を探していますか」「そのように考えた理由を教えてください」と、答えを含めない聞き方を用意します。

それでも完全に止まったら、必要な補助をして次の課題へ進むことはできます。その場合は「自力で進めた」と記録せず、どの説明を加えたかを残します。参加者には、操作能力や知識を採点する場ではないと伝え、途中でやめたり答えを保留したりできるようにします。無理に話し続けてもらうより、行動後に落ち着いて確認した方がよい人もいます。

記録と個人情報の扱いを先に説明する

録画や画面共有を使うなら、目的、閲覧する人、保存先、保存期間、削除の担当を事前に説明し、同意を確認します。協力者の仕事用画面に、顧客名やメール通知が映らない準備も必要です。テスト用の氏名やメールアドレスを使う場合は、実在する第三者の情報を勝手に使わず、受け口とデータの扱いを管理できる形にします。操作確認に不要な機密情報を集めない設計が基本です。

当日の運営は、進行役と記録役を分けられると観察に集中しやすくなります。一人で実施するなら、記録する項目を絞り、終了直後に記憶を補足する時間を取ります。例えば一回の予定を「説明、課題、振り返り」に分け、間に余裕を置きます。参加者の利用環境や疲労に合わせて調整し、長時間に多くの課題を詰め込むことを目的にしません。

観察記録を、根拠のある修正指示に変える

見た事実、解釈、修正案を別々に書く

「料金表が分かりにくい」という一文だけでは、後から担当者が何を直せばよいか判断できません。GOV.UKの調査結果の分析ガイドは、観察したことと意味の解釈を分けて整理する方法を説明しています。企業のLPでも、事実、仮説、修正案の欄を分けると、確認していない原因を断定しにくくなります。

以下は実測結果ではなく、記入方法を示す架空の記録例です。時間や人数を成果らしく付け足す必要はありません。どの画面で何が起き、何を確かめるために修正するのかが、制作会社に伝わることを優先します。

人数の割合だけで優先度を決めない

多数の人が写真を好まなかったことと、一人が送信エラーから復帰できなかったことは、影響の種類が違います。優先度は、目的を達成できなくなるか、誤った契約理解につながるか、対象となる人や場面がどれだけ重要か、修正の影響がどこまで及ぶかを合わせて判断します。少人数調査の「何人中何人」を、そのまま全訪問者の発生率とは扱いません。

公開前に直すべき問題には、申し込みの完了を妨げるもの、価格や提供範囲の重大な誤解、想定する端末で主要操作ができないものなどが挙げられます。追加調査に回す問題には、原因が複数考えられるものや、対象ユーザーの条件が足りないものがあります。見た目の調整を後回しにする場合も、不要と決めつけず、判断した理由と再検討の時期を残します。

観察で入力や送信の問題が見つかった場合は、問い合わせフォームの改善手順を使って、質問の必要性、エラーからの復帰、受付・通知の確認を修正依頼へ落とし込めます。

参加者の提案を、そのまま仕様にしない

「大きな赤いボタンがあればよい」という提案が出ても、解決したい問題はボタンの色とは限りません。今どこから相談できるか分からないのか、押した後の連絡が不安なのか、そもそもサービスの対象だと思っていないのかを確認します。提案を尊重することと、その案を無検証で採用することは別です。発言の背景を整理し、他の人の行動や実際の受付条件と合わせて修正案を作ります。

制作会社に渡すときは「もっと分かりやすく」ではなく、「初回相談に費用が発生しない条件を、入力を始める前に理解できるようにする」と目的を伝えます。文言を指定する必要がある部分と、制作側が案を出せる部分を分ければ、細かな指示の往復を減らせます。条件の正確さは事業者が確認し、配置や表現は制作側と検証する、といった責任の持ち方も明確にします。

修正後の再確認と公開判断をつなぐ

同じ課題で、意図した問題が解消したかを見る

修正した画面だけを社内で見て「よくなった」と結論にすると、利用者の理解が変わったかは分かりません。最初に確かめたかった課題に戻り、説明を加えずに目的を達成できるかを再確認します。できれば内容をまだ知らない対象者に見てもらい、同じ人に再協力してもらう場合は、前回の記憶が影響することを記録します。修正前後を比較する条件をそろえる意識が必要です。

また、一箇所の改善が別の問題を生まないかを見ます。料金の説明を追加して相談ボタンが極端に下へ移動した、注意書きが増えて重要な条件を見分けにくくなった、固定ボタンが入力欄を隠した、といった点です。変更箇所の前後から一連の行動をたどり、PCとスマートフォンで主要な操作を確認します。図や写真を差し替えた場合も、意味が文言と一致しているかを点検します。

テストを終えても、実装の動作確認は別に行う

内容を理解できたことと、本番システムが正しく動くことは異なります。試作で申し込み完了画面を表示できても、本番でメールが受信されるとは限りません。公開前には担当者を決め、実際の受信、通知先、完了画面、入力エラー、リンク先などを確認します。受付テストは関係者と予定を共有し、テスト分を実際の商談として数えないようにします。

公開の判断用メモには、「確認した対象と条件」「公開前に修正した問題」「残っている問題」「公開後に確かめること」をまとめます。全員が好きと言ったかより、主要な目的を妨げる問題が残っていないかを判断できる記録にします。特定の端末や支援技術での操作を未確認なら、その範囲を明記します。確認範囲を隠して完成度を大きく見せても、次の改善には役立ちません。

文字・配色・キーボード操作・入力エラーなどの点検は、アクセシビリティ改善の確認項目と合わせて進められます。利用者の行動観察と、実装上の点検の役割を分けて確認しましょう。

制作会社と進めるための依頼メモとよくある疑問

見積もり前に確認する実施範囲

ユーザーテストを制作会社に依頼する場合は、参加者募集、課題設計、試作、実施、分析、修正、再確認のどこまでが含まれるかを確認します。「テスト込み」だけでは、社内担当者の画面確認なのか、対象に近い人の利用観察なのかが分かりません。人数だけで価格を比べず、検証する疑問、対象条件、成果物、修正回数の扱いをそろえて比較します。

依頼メモの例は「初めて設備点検を相談する担当者が、スマートフォンで対応条件と費用発生の段階を理解できるかを確認したい。公開前に一度修正できる期間を取り、観察記録と修正理由を共有してほしい」です。これに公開予定日、既存の問い合わせで多い疑問、利用できる試作を添えます。細部が未定でも、誰のどの判断を助けたいかが伝われば、実施範囲を相談しやすくなります。

公開まで時間がない場合はどこから着手するか

時間が限られるなら、すべてのページ要素を広く評価しようとせず、主要な相談経路と重大な誤解を生みそうな条件に絞ります。例えば「対象サービスを判断する」「費用の条件を確認する」「相談へ進む」の三場面です。実施後に修正する時間がない調査は、問題を見つけても対応できません。参加者の日程だけでなく、分析と制作の時間を先に確保します。

どうしても利用者を集められない場合は、社内で仮の課題を使った点検を行い、それを利用者による検証済みとは呼ばず、未検証の疑問を残します。公開後に相談の内容や利用状況から優先順位を付けて補います。限られた条件でできたことを正確に扱う方が、無理にテスト済みの体裁を作るより、次の判断が明確になります。

結果を次の記事や営業資料にも生かせるか

何度も説明が必要になった条件は、LPの補足だけでなく、比較検討向けの記事や営業資料のテーマ候補になります。ただし、参加者一人の発言から「顧客は全員こう考えている」と広げないことが大切です。営業の問い合わせ記録、公開後のアクセス状況、別の利用者への確認を重ね、同じ疑問が実際に繰り返されるかを見ます。

LPは短くすれば必ず伝わるわけでも、情報を足せば必ず納得されるわけでもありません。利用者が判断する順番に合わせ、必要な条件を見つけて理解できるかを確認することが改善の出発点です。AcquaへのLP制作の相談では、デザインの希望と合わせて、公開前に確かめたい疑問や、営業で説明に困っている点も共有してください。課題の整理から制作範囲を検討できます。

出典の確認日：2026年9月9日。本文で紹介した公開事例は各運営主体の報告に基づき、Acquaの担当実績や成果として記載したものではありません。図解は本記事の手順を整理したイメージです。