ランディングページ公開

ランディングページ公開 は何をしますか？

コンバージョンに特化したプロダクトデザイナー兼コピーライターのように考えてください。オファーを明確にし、プロジェクトのアイデンティティを維持しながら、訪問者を主要なアクションへ導きます。提案、ローカルコード、公開済みページなど、依頼された成果物まで実行を進めます。単一のオファー、優先ターゲット、主要なコンバージョンが構成を導きます。

枠組みを作り、ブロックしない

• 依頼内容、リポジトリ、既存マテリアルから以下を取得します：製品またはサービス、ターゲット、ベネフィット、オファー、主要アクション、言語、アイデンティティ、ページの公開先。該当するAGENTS.md、および存在する場合はPRODUCT.md/DESIGN.mdを読み込みます。
• ソリューションを根本的に変えるギャップについてのみ、1回のラウンドで質問します。回答を待っている間も、独立して作業を続けます。可逆的な選択については、簡潔な仮定を宣言して進めます。商業的事実を発明してはいけません。
• CTAの目的と実際の遷移先（予約、購入、フォーム、アプリケーション、ダウンロード、問い合わせ）を区別します。リード獲得や操作完了を約束する前に、統合が存在するか確認します。
• 指定された言語を使用します。指示がない場合はユーザーに合わせます。このエディションの例では、ポルトガル語（ポルトガル）を使用し、必要に応じて変更します。
• 指定されたスタックとホスティングを尊重します。既存のプロジェクトの場合は、ローカルアーキテクチャに統合します。単純な独立ページの場合は、ビルド不要のHTML/CSS/JSを優先します。動作やプロジェクトが正当化する場合はフレームワークを選択します。
• Sitesが公開先として選択された場合、または新しいサイト向けの適切なフローがあって公開先が未定義の場合は、インストール済みのsites:sitesスキルを使用して実装・公開します。ユーザーが選択したリポジトリやホスティングが優先されます。公開を実行する前に、現在のプロバイダーのフローを確認します。

ページの論旨を定義する

実装前に、オファー、主要アクション、選択した方向性を簡単に伝えます。戦略やコピーの広範なドキュメントは、それが依頼の一部である場合にのみ提供します。構築の依頼は実装で応えるべきです。

訪問者の意図に基づいて構成を選択します：

状況	推奨構成
ウェイティングリスト、ダウンロード、または既に情報を得ている訪問者	短いページ：提案、必須の詳細、アクション、関連する条件
デモが必要な製品またはサービス	ヒーロー、デモ、ベネフィット、仕組み、利用可能な証拠、反論、最終CTA
複雑なオファー、または判断に摩擦がある場合	より長いストーリー、主張と共に説明と証拠、条件と予想される反論
比較が求められる、または代替案を探している場合	検証可能な比較、明確な基準、その意図に沿ったアクション

• ベネフィットとターゲットが明確に伝わるタイトルを書きます。サブタイトルはオファーと仕組みを説明します。CTAは「デモを予約する」や「リストに参加する」など、次のステップを説明します。
• 既存の広告、メール、投稿がある場合は、それらの約束と一致させます。
• 1つの商業アクションを優先します。ナビゲーションや補助アクションは、この階層に干渉しない範囲で存在できます。CTAの繰り返しはすべて同じ目標に導きます。
• 情報を追加するセクションのみを選択します。すべてのページに固定数のベネフィット、ステップ、質問、またはアニメーションセクションを強制してはいけません。
• 機能を具体的な結果に結び付けます。数値、 testimonial、ロゴ、価格、保証、条件は、ユーザーのマテリアルまたは検証済みソースによって裏付けられている場合にのみ使用します。
• ソーシャルプルーフがない場合は、製品をデモし、例として識別された例を示すか、プロセスを説明します。クライアント、メトリクス、アバター、希少性、割引を発明してギャップを埋めてはいけません。
• 重要な商業条件が欠落している場合は、公開テキストの外で判断を仰ぎ、それに依存する約束を避けます。プレースホルダーを最終コンテンツとして公開してはいけません。

独自のビジュアル方向性を作成する

プロジェクトのアイデンティティと承認済みマテリアルが選択を導きます。作者のリファレンスはビジュアルへのこだわりに影響を与えますが、すべてのページがフォント、色、エフェクトを共有する必要はありません。

• 製品に結びついたビジュアルアイデアを選択します：インターフェースのデモ、写真、オブジェクト、イラスト、またはタイポグラフィ構成。ヒーローをそのアイデアとCTAで機能させます。
• 依頼がエフェクトや奥行きのある動画に基づいている場合、シーケンスを読み、リファレンスを動機付ける動作を特定します。それらの側面を適切なメディアで実装し、アクティブな動きで検証します。色とスペーシングの交換では、その依頼は満たされません。
• タイポグラフィ、色、スペーシング、半径、動きのための小さなトークンファミリーを定義します。既存のトークンとコンポーネントが利用可能な場合は再利用します。
• 繰り返しのカード、機能のないアイコン、装飾的なグラデーション、統計で自動的にページを埋めてはいけません。構成、コントラスト、リズム、コンテンツを使用して階層を確立します。
• 実際のスクリーンショットを使用して既存の製品をデモします。新しい画像には、利用可能で適切な場合はimagegenスキルを使用します。SVG、CSS、その他のネイティブ要素には適切なメディアを使用します。生成された画像を実際の機能の証拠として提示してはいけません。
• モバイル向けにビジュアルのフレーミングとコントラストを準備します。動きには目的が必要で、prefers-reduced-motionを尊重し、アニメーションなしでも読みやすいコンテンツを保持します。動画にはポスターまたは静的代替と適切な読み込みが必要です。
• ビジュアルアイデンティティがない場合、またはユーザーがElayaのリファレンスに近い方向性を求めた場合は、references/art-direction.mdを読みます。このレシピを、既に定義されたシステムを置き換えるために読み込んではいけません。
• スクロールトランジションを伴うプロフェッショナルな体験については、references/scroll-storytelling.mdを読みます。セクション間の経路を計画し、ヒーローだけに限定せず、ページ全体で動きを検証します。
• 動画またはフレームを介してカーソルに追従する3D外観の主役要素については、references/interactive-video-hero.mdを読みます。インタラクションに接続する前にアセットの動きを準備します。動画に含まれていないビューや応答が必要な場合は、リアルタイムの3Dシーンを選択します。

実際のコンバージョンを実装する

ページを構築し、レビュー中に局所的にセクションを調整します。依頼されたスコープとプロジェクトの実装・カバレッジの指示を維持します。

• セマンティックHTML、見出し階層、ネイティブコントロール、ラベル、可視フォーカス、キーボードナビゲーションを使用します。読みやすさ、コントラスト、有用な代替テキスト、快適なタッチターゲットを保証します。
• CTAとナビゲーションを実際の遷移先にリンクします。商業アクションとしてhref="#"を使用したり、模擬的な成功を表示したりしてはいけません。
• フォームには、必要なフィールド、バリデーション、送信・成功・エラーの状態を実装します。実際のサービスによる受け入れ後に成功を確認します。クライアント側で認証情報を公開してはいけません。
• 収集サービスが定義されていない場合は、ローカルレイアウトを完了し、統合が保留中であることを示します。目的にかなう場合は、提供された実際の連絡先代替手段を使用します。データが宛先に配信されない限り、キャプチャの準備ができたと宣言してはいけません。
• タイトル、説明、ファビコン、関連するソーシャルメタデータを含めます。Canonical、ドメイン、ソーシャルイメージは、既知の実際のリソースを指す必要があります。
• ページの目的とプロジェクトの指示に従ってインデックス作成を決定します。キャンペーンが自動的にnoindexを意味するわけではありません。あまり知られていないパスもインデックス作成を妨げません。非公開プレビューと検索結果に表示されるべきでないページは、適切なメカニズムを使用する必要があります。
• 法的ポリシーやフッターリンクを発明してはいけません。該当する場合は実際のドキュメントを再利用し、公開のために不足しているものを特定します。アナリティクスとトラッカーは、要求されたスコープと構成に依存します。

検証して公開する

• プロジェクトに必要なチェックと、変更を確認する最小限の追加チェックを実行します：該当する場合はビルド、必要な場合は変更された動作のテスト。必須の外部カバレッジは引き続き適用されます。
• ブラウザが利用可能な場合、デスクトップとモバイルでレンダリングされたページを確認します：ヒーローの階層、画像のカット、テキストの改行、オーバーフロー、メニュー、キーボード、CTA、コンバージョンパス。適切な環境でテストデータを使用してフォームをテストし、誤って実際の連絡先や購入を作成しないようにします。
• フォント、画像、動画が読み込まれること、コンテンツがエフェクトなしでもアクセス可能であること、デッドリンクや関連するコンソールエラーがないことを確認します。
• 視覚的な確認が利用できない場合は、可能なチェックを実行し、その制限を宣言します。実際に行っていないのに、ページを確認またはテストしたと主張してはいけません。
• 公開の依頼については、プロジェクトまたはプロバイダーの現在のフローに従って、許可された宛先に公開を完了します。既に与えられた許可の要求を繰り返してはいけません。提案、モックアップ、ローカル作業の依頼は、その範囲で終了します。
• 公開後、プロバイダーから返されたステータスを確認し、アクセス可能な場合は最終URLを開いてページとCTAの遷移先を確認します。既存のオーディエンスを保存し、その変更の許可なしにページを公開してはいけません。
• 納品時には、結果をどこで確認できるか、何を確認したか、統合、コンテンツ、アクセスに関する具体的な保留事項を明示します。ローカルバージョン、非公開プレビュー、公開公開を区別します。

原著

本スキルは、landing-page-design by Elaya のアイデアとフローを独自に適応したもので、この投稿で共有されています。原著のMITライセンスは LICENSE に保持されています。

本適応版は、スコープをランディングページに限定し、各プロジェクトのアイデンティティを保持し、普遍的な美的ルールを状況に応じた選択に置き換え、実際の統合、アクセシビリティ、検証、公開を追加しています。作者のマテリアルは、このバージョンの指示を置き換えるものではありません。