ソースの約束から始める
設計作業の前に、ソースの主張、対象、オファー、条件、CTAを記録する。その意味は一般的なブランドスローガンではなく分かりやすい言葉で残す。たとえばソースで「無償の移行アセスメント」を提供するとしているなら、ページ上部にその旨を明確に記す。
誰が何を受け取るかの短い説明を追加し、主要なCTAを近くに配置する。価格、適格性、契約、地域、時期など重要な条件は約束の近くに置く。メッセージマッチは字義どおりの繰り返しではなく連続性である：ページでは短い広告で説明し切れなかった点を補える。
ソースの主張、ページヘッドライン、補助説明、資格条件、CTAを記録する。公開前に矛盾を解消する。
主要な成果を1つに絞る：連絡を依頼する、定義済みの商品を購入する、トライアルを開始する、リソースにアクセスさせる、など。
次の決断を見やすくする
視覚的階層はサイズ、間隔、コントラスト、位置、グルーピングが注意を導く順序である。モバイルでは「約束、説明、CTA、証拠、詳細、CTAの再掲」の順序を使う。訪問者はレイアウトを読み解く前にオファーを理解すべきである。
主要CTAには具体的な文言、十分なコントラスト、余白を与える。二次的な行動は控えめにする。メニュー、チャット、同意通知、バナー、カルーセルが小さい画面でCTA、入力フィールド、フォーカス状態、重要条件を覆い隠さないようにする。
初めて見る人に何が提供され、誰向けで、次に何をするかを尋ねる。不確実ならコピーかレイアウトの問題である。
一般的な幅、ズーム、翻訳で長くなった文字列をチェックする。操作は誤タップなく届く位置にある必要がある。
誇張せずに主張を裏付ける
疑いに答える種類の証拠を用いる：能力に関する懸念には機能説明、実行可能性には導入事例、予算には価格説明、リスクにはポリシーを示す。可能ならケーススタディの出典と日付を明示する。顧客の成果に影響した条件は、その顧客の結果として提示するのではなく条件として述べる。
事実に基づき出典が明示された推薦文のみを用いる。FTC（米国連邦取引委員会）の指針は、自社サイトに虚偽または捏造した推薦を掲載した事業者が U.S. Consumer Reviews and Testimonials Rule の下で責任を負い得ることを示す。引用をでっち上げたり意味を変えたり、重要な関係を隠したり、肯定的評価の対価を払ってはいけない。奨励された推薦、規制対象の主張、国境を越えるキャンペーンについては法務・コンプライアンスの専門家の確認を求める。
懐疑的な訪問者がその主張を判断するために何を必要とするかを問い、その証拠を提供またはリンクする。
製品の機能、観察された顧客成果、予測は区別して記載する。
より多くの人に使いやすいフォームと操作にする
W3C のフォームに関するガイダンスは、各コントロールにラベルを付け、完了手順を示し、明確な成功とエラー通知を行うことを推奨する。プロセス完了に必要な情報だけを求め、表示ラベルと短いフォームで摩擦と不要なデータ収集を減らす。
ヒントテキストを唯一のラベルにしたり、色だけをエラー信号にしたりしてはいけない。送信前に必須フィールドと形式を明示し、訂正方法を説明する。キーボード操作と確認フィードバックをテストする。WCAG 2.2 Level AA は通常テキストで 4.5:1、大きなテキストで 3:1 のコントラスト比を求め、テキストがリサイズされても機能し続けることを期待する。技術的チェックはユーザーテストや現地の助言に代わるものではない。
全てのコントロールを Tab で辿る。フォーカスは見えること、順序は読み順に従うこと、モーダルには明確な退出手段があること。
決済や機微な個人データについては、入力項目を最小化し、適格なセキュリティ、プライバシー、決済コンプライアンスの確認を得る。これはコンプライアンス評価ではない。
ヒーローを速く、レイアウトを安定させる
Largest Contentful Paint（LCP）は初期表示の最大のコンテンツ要素の読み込み性能を測る指標である。Google は LCP を 2.5 秒以内、Interaction to Next Paint（INP）を 200 ミリ秒未満、Cumulative Layout Shift（CLS）を 0.1 未満に努めることを推奨している。これらは診断指標であり、コンバージョンを保証するものではない。
モバイル訪問で実際にどの要素が LCP になるかを測定する：ヒーロー画像や見出しが該当することがある。web.dev は LCP リソースを初期 HTML で発見可能にすることを推奨し、LCP 画像を遅延読み込みしてはいけないと警告する。画像、埋め込み、バナー、フォームエラー用のスペースを確保して、クリック準備ができた訪問者の下でレイアウトが移動しないようにする。
タグ、フォント、実験、チャット、動画を監査する。必要なコンポーネントを最適化してテストし、同意、セキュリティ、コアフローのツールを盲目的に削除しない。
ヒーローのレンダリング、CTA、バリデーション、確認、ハンドオフをテストする。最初の表示が速くても、行動が壊れていれば意味がない。
約束された経路をプレフライトし是正する
ランディングページは公開後に創出物、価格、フォーム、タグ、依存関係の変更で変化する。キャンペーンや大きなリリースの前に、ソース URL、メッセージマッチ、モバイルレイアウト、キーボード経路、CTA、確認、同意の挙動、法的リンクをチェックする。変更履歴とテスト済みの差し戻し手段を保管する。
SIU の役割は障害報告ではなく、事前的な稼働性最適化と是正対応である。可用性とアクション経路のプレフライトを実行し、到達不能な宛先、壊れたCTA、ブロックされたアセット、失敗するフォーム、欠落する確認を修復する。欠陥のあるタグ、クリエイティブ、依存関係は既知の良好な体験にロールバックできるよう準備する。
クリティカルパスを検証する担当者とロールバックを許可された担当者を一人ずつ決める。
視覚的な実験よりも、誤ったオファー、失敗する操作、アクセス不能なブロッカー、不安定なレイアウトを優先して修正する。