DX+
GrowNewEngine
数字と導線で売上改善を支援
メニュー
改善レポート

自社でLPデザインを検討する:AIとの壁打ちからHTML案を作るまで

自社サイトの方向性をAIとの壁打ちで文章にまとめ、参考サイトの比較からHTMLベースのランディングページ案へ落とし込む手順を解説。検討用の依頼文と、問い合わせ・商談までを見るKPIの例を紹介します。

LP改善・WEB活用レポート
自社LPのデザイン検討:AIとの壁打ちで方向性を整理し、参考サイトを比較してHTML案へ落とし込む3ステップ

自社でLPデザインを検討する:AIとの壁打ちからHTML案を作るまで

デザインの前に、誰のどんな判断を助けるかを決める

自社でランディングページ(LP)のデザインを検討するときは、先に「誰に、何を伝え、どの行動につなげたいか」を文章にまとめます。その文章を判断の軸にして参考サイトを比較し、HTMLで確認できる案へ落とし込むと、見た目と営業上の目的を結び付けて検討できます。

GrowNewEngineでは、サイトを顧客獲得・教育・診断・信頼形成のための営業基盤として捉えます。LPでも、提供する価値を理解してもらい、自社の課題を整理し、相談へ進める流れを考えることが出発点になります。

本稿は、自社でデザインを検討するための手順を整理した解説レポートです。以下の依頼文、構成案、数値は説明用の例であり、実際の参考サイト比較やHTML案の制作を完了した記録、改善実績を示すものではありません。

1. 自社サイトの方向性をAIとの壁打ちで整理する

まず、想定する顧客、顧客が困っていること、提供できる支援、相談すると分かることを書き出します。現在のページや問い合わせ内容から分かる事実と、これから確かめたい仮説は分けておきます。AIには、その情報の不足や矛盾を質問してもらい、答えながら整理します。

壁打ちの依頼文の例

自社サイトのLPを検討しています。対象顧客、顧客の課題、提供できる支援、根拠となる情報、ページを読んだ後に取ってほしい行動を整理したいです。これから渡す情報だけを事実として扱い、不明点は質問してください。実績、料金、対応範囲を補って作らないでください。最初に不足する情報を確認し、回答後に方向性を短い文章にまとめてください。

この依頼に続けて、自社で公開できる情報を渡します。顧客の個人情報や社外秘の売上データを含めず、必要に応じて匿名化した課題や集計値で説明します。

方向性メモに残す項目

対象顧客:誰が、どのような状況でページを読むのか。

顧客の課題:何に困り、何を判断できずにいるのか。

提供価値:その課題に対して、自社がどこまで支援できるのか。

根拠:公開できる事例、支援の手順、成果物の例など、説明を裏付ける情報は何か。

次の行動:読者にどの入口から進んでもらい、その先で何を得られるのか。

未確認事項:実績の公開可否、提供条件、掲載表現など、誰が確認する必要があるのか。

例えば、売上改善支援のLPなら「問い合わせはあるが商談につながらず、改善箇所が分からない担当者に、問い合わせから商談までの数字を整理する考え方と支援の流れを伝える」といった形でまとめられます。これは検討用の一例です。実際の顧客像と訴求は、自社の状況に合わせて人が決めます。

2. 参考サイトを、採り入れたい理由とセットで整理する

方向性がまとまったら、参考サイトを比較します。「雰囲気が好き」という感想に加え、どの部分が自社の顧客の判断を助けそうかを書きます。URLと確認日、対象の箇所を残すと、後で案を見直す際にも理由を共有できます。

最初の画面では対象顧客と提供価値が伝わるか、本文では課題から解決方法へ自然に進めるか、相談ボタンの周囲では相談後の流れが分かるかを確認します。文字量、余白、配色、スマートフォンでの読みやすさも、情報を伝える目的に照らして見ます。

記録は「参考URL:未選定/確認日:未記入/参考箇所:相談までの手順/採り入れる理由:初めての相談で何が起きるかを伝えたい/自社への置き換え:確認済みの相談手順を掲載」のように残せます。参考サイトの文章や画像をそのまま転用せず、情報の並べ方や説明の工夫を自社向けに考え直します。

比較では、自社の方向性に合わない部分も記録します。例えば、詳細な説明を読んでから相談する顧客に向けたページなら、参考サイトの短いコピーだけでは判断材料が足りないかもしれません。他社の見た目だけから、そのサイトの成約率や成果を推測しないことも大切です。

3. デザインの前に、LPの情報の順番を決める

次に、方向性メモと参考サイトの比較をもとに、ページの構成を文章で作ります。売上改善支援を例にすると、「対象顧客と提供価値 → よくある課題 → 確認する数字 → 支援内容と進め方 → 公開できる根拠 → 相談の流れ → 相談の入口」という順番が検討できます。

各ブロックには役割を一つずつ持たせます。「確認する数字」なら、訪問、問い合わせ、商談、契約のどこで流れが止まっているかを見る考え方を伝えます。「相談の流れ」なら、何を伝えればよいか、次に何を確認するかを説明します。

公開できる実績がない箇所を架空の成果で埋める必要はありません。事実に基づく作業手順や、説明用と明記した成果物の例で、支援内容を具体的に伝えます。料金や相談条件は確認済みの内容だけを使います。

4. HTMLベースの案にして、文章と導線を確認する

構成が決まったら、HTMLとCSSで検討用のLP案を作ります。HTMLで文字、見出し、ボタン、各ブロックの順序を表現すると、実際の画面幅に合わせて、情報量や読んだ後の行動を確認しやすくなります。

HTML案を依頼するときの文章の例

以下の方向性メモ、参考サイトの比較メモ、ページ構成、確認済みの掲載情報を使い、社内検討用のLP案をHTMLとCSSで作成してください。各ブロックの目的が伝わる見出しと本文を置き、スマートフォンでも読める構成にしてください。見出しの順序、文字の読みやすさ、キーボードでの操作にも配慮してください。不足する実績や料金は創作せず、確認事項として分けてください。フォーム送信や外部サービス接続は実装せず、相談ボタンの遷移先は提供されたものだけを使ってください。未指定なら遷移先が未設定であると分かる表示にしてください。

依頼には、まとめたメモと掲載情報を添えます。AIがURL先を確認できない環境では、参照箇所を確認したことにせず、自分が整理した観察内容を渡します。最初は一つの案で情報の不足を確認し、別案を作る場合は「課題の説明を先に置くか、支援の流れを先に置くか」など、比較したい点を決めます。

検討用のHTML案は、そのまま公開する前提にはしません。既存サイトへ反映するときは、共通のヘッダーやフッター、相談先、計測方法などとの整合を担当者が確認します。

5. 見た目と一緒に、相談までの流れをレビューする

案を確認するときは、対象顧客の立場で「何を改善するサービスか」「自社に関係があるか」「相談すると何が分かるか」を読み取れるかを見ます。説明の根拠があるか、対応範囲を広げすぎていないかも確認します。

スマートフォンでは、長い見出しが読みづらくないか、横にはみ出す箇所がないか、相談ボタンが見つかるかを確認します。ボタンに進む前に必要な情報が揃っているか、リンク先とボタンの表現が一致するかも見ます。

レビュー記録には「気になる箇所/読者が迷う理由/修正案/確認担当」を残します。例えば「相談ボタンの直前に説明がない/相談後の流れが分からない/確認済みの相談手順を追加する」と書くと、修正の目的を共有できます。

6. 公開後は問い合わせ・商談までの数字で見直す

公開前に、訪問 → 相談ボタンのクリック → 問い合わせ完了 → 商談 → 契約の流れで、どの数字を記録するかを決めます。クリックと問い合わせ完了は別の行動として扱い、見た目の評価と実際の結果を分けて確認します。

LP問い合わせ率 = LPへの訪問にひも付く問い合わせ完了数 ÷ LP訪問数 × 100。

商談化率 = その問い合わせのうち商談へ進んだ件数 ÷ 対象の問い合わせ完了数 × 100。

例えば、対象期間のLP訪問が1,000件、問い合わせ完了が10件、その問い合わせから商談へ進んだ件数が3件なら、問い合わせ率は1%、商談化率は30%です。これは計算を説明するための仮定で、実績や目標値、業界平均ではありません。分母が0の場合は算出不可とします。

比較する期間、訪問の定義、LPと問い合わせをひも付ける方法、問い合わせから商談へ進むまでの観測期間を揃えます。広告の配信先や流入元の変化も記録し、公開前後の数字の差だけでデザインの効果を断定しないようにします。

訪問はあるが相談ボタンが押されないなら訴求や判断材料を、クリックはあるが送信されないなら遷移先や入力時の負担を、問い合わせ後に商談へ進まないなら相談内容とサービスの適合を確認します。確認した結果を方向性メモへ戻し、次に変更する箇所を決めます。

自社のLPの方向性を整理したい方へ

まずは「対象顧客・顧客の課題・提供できる支援・読後の行動」を短い文章にし、既存のページで伝わっているかを確認してみてください。参考サイト選びとHTML案の作成は、その文章をもとに進められます。

相談をご希望の場合は、ページ下部の「診断を相談する」から、お問い合わせ種別で「改善レポート内容の相談について」を選び、対象ページと「方向性がまとまらない」「訪問はあるが問い合わせが少ない」など、整理したい点をお知らせください。