Communitygithub.com

ランディングページクラフト

Favourが実際に構築したランディングページのプロセスと美的感覚をエンコードしたスキル。テンプレート感のない、独自の視点を持つページを、コンセプト立案からコード実装まで一貫して生成します。

ランディングページクラフト とは?

このスキルは、「Allowance」「didii」「Revolut Founder Mode」「TrashPay」「FlutterBytes」などの実プロジェクトの構築プロセスと、Favour自身による複数回のテストビルドでのフィードバックを反映した、ランディングページ制作のための包括的なワークフローです。単なる「ベストプラクティス集」ではなく、彼が繰り返し採用し、修正を加え、拒否してきた具体的なルールとプロセスが凝縮されています。 主な機能は、(1) ブランド名や対象ユーザーなどの最低限の情報から、具体的なコンセプトを導き出すための「概念とグレード」の事前計画、(2) 各セクションごとの詳細なチェックリストに基づく設計、(3) ヒーローセクションは1つの核となるアイデアに基づき、2カラムセクションでは両方のカラムに意味のあるコンテンツを配置し、全セクションにアニメーションを実装するなどの「ハードルール」の遵守、(4) 過去のプロジェクトから蓄積された「シグネチャーコンセプト」と「タイプフェイス」のギャラリーの活用、そして(5) フォームはGoogleフォームと連携する点などが含まれます。 このスキルは、Next.js、TypeScript、Tailwind CSS、Framer Motionをデフォルトのスタックとして使用し、Claude Codeなどの実際にレンダリング結果を視覚的に確認できる環境での使用を前提としています。目的は常に「説明されて初めて理解できるコンセプト」ではなく、「一目で意図が伝わる、独自性のあるページ」を生成することです。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mustaphafavour1/landing-pages-skills/tree/main/landing-page-craft

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

ランディングページクラフト は何をしますか?

これは、Favourが実際にテンプレート感のないランディングページを構築する方法をまとめたものです。彼自身が過去に行ったAllowance、didii、Revolut Founder Mode、TrashPay、FlutterBytes Conferenceサイトの構築に関する会話から抽出され、このスキルを使って行われたテストビルドに対する彼の直接のフィードバックによって繰り返し洗練されてきました。これは単なる「ランディングページのベストプラクティス」ガイドではありません。彼が何度も採用し、修正を求め、受け入れを拒否してきた具体的な方法をまとめたものです。また、これは生きたドキュメントでもあります:開始前に references/build-log.md を確認し、終了後にそれを更新してください。

毎回の目標:本物の視点を持った何かを作ること。単にクライアントの名前を差し替えただけの、有能ではあるがテンプレート的なものではありません。そして重要なのは、一目で明白で意図的だとわかるコンセプトであって、説明されて初めて意味がわかるものではないということです。


何よりも先に:作業するのに十分な情報はあるか?

もし与えられたブリーフに、コンセプトを結びつけるための本当のプロダクトが含まれていない場合、つまり、名前、ターゲットユーザー、トーン、このアイデアを一般的なものから区別するものが何もない場合は、作業を止めて質問してください。1つか2つの鋭い質問は、後でそれが合わないことが判明するような仮の方向性をでっち上げるよりもはるかに優れています。

質問すべき、より具体的な2つの場面:

  • あるセクションが明らかに実際の写真(抽象的なものやベクター表現ではなく)から恩恵を受ける場合、作業を進める前に写真を依頼してください。それが入手できない場合は、その旨を伝え、ストックフォトを偽装する代わりに、グラデーションとラインアートで代用してください。
  • あるセクションに代表的なサンプルコンテンツ(サンプル名、サンプルカード、プレースホルダーデータ)が必要な場合、まずそのバージョンを1つ提案し、変更を明示的に促してください。自分の推測を黙って確定させないでください。

十分な情報がある場合(実際の名前、実際のオーディエンス、実際の差別化ポイント、たとえ大まかなものでも)は、先に進んでください。


ビルドスタック

デフォルトのターゲットは、Next.js、TypeScript、Tailwind CSS、Framer Motionです。これが、このスキルの元となったすべてのプロジェクトで使用されている実際のスタックです。納品物として、プレーンなHTMLやバニラJSを使用しないでください。

もし作業環境がそのスタックをライブでレンダリングできない場合は、黙って弱いものに置き換えるのではなく、その旨をはっきり述べてください。それでも実際のReactコンポーネントを構築し、バニラJSは決して使用せず、プレビュー用にはCSSトランジションまたはWeb Animations APIを使用して意図したモーションを近似してください。ただし、実際のNext.js/TypeScript/Framer Motionのコードベースもダウンロード可能なファイルとして提供し、特に出力に対する実際の視覚的判断が簡単なチェックよりも重要になり始めた場合、この作業は実際にそのスタックを実行してスクリーンショットを撮影できる環境(例えばClaude Code)に属するものであることをはっきり述べてください。


フォームは常にGoogleフォームに送信する

サイト上のすべてのフォーム(ウェイティングリスト、お問い合わせ、申し込み、登壇応募、注文/予約など)は、サイト独自のデザインで構築されたブランド化されたカスタムフォームであり、その送信はGoogleフォームのプリフィルリンクを介してバックグラウンドでGoogleフォームに転送されます。訪問者は生のGoogleフォームを見ることはありません。サイトのスタイリングを見て、データはGoogleフォームのレスポンス(およびリンクされたレスポンススプレッドシート)に保存されます。

これは、サイトにフォームが必要だとわかったらすぐに依頼してください。写真の場合と同様に、これは人への依存関係です。サイトのフォームが収集するフィールドに一致するGoogleフォームを作成し、そのプリフィルリンクを送り返すように依頼してください。次に、各オンページフィールドを、そのプリフィルリンクから解析された対応するGoogleフォームのエントリIDにマッピングし、フォームの送信ハンドラーでそれに送信します(標準的なアプローチは、entry.<id> パラメータを使用してフォームの /formResponse エンドポイントにPOSTするか、同等の方法です)。もし人がまだリンクを提供していない場合は、ブランド化されたフォームUIを完全に構築しますが、送信先は明確にスタブしてフラグを立てておき、エンドポイントをでっち上げないでください。

ほとんどの人はGoogleフォームのプリフィルリンクがどこにあるか知らないので、常にその取得手順を人に伝えてください:

  1. Googleフォームを編集モードで開きます。
  2. 右上の三点リーダー ⋮ オーバーフローメニューをクリックします。
  3. 「プリフィルされたリンクを取得」を選択します。
  4. 各フィールドに認識可能なプレースホルダー値(例:フィールド名自体を入力)を入力し、下部の「リンクを取得」をクリックします。
  5. ポップアップで「リンクをコピー」をクリックして送信します。

そのリンクには各フィールドの entry.<id> が含まれており、ブランド化されたフォームのフィールドをGoogleフォームにマッピングするために必要なものそのものです。


タイプとカラーは、一人で決めずに、人と一緒に選ぶ

どちらかを決定する前に、黙って決めるのではなく、短いビジュアルチェックインを行います:

  • タイプ: references/typeface-library.md をチェックして、最近使いすぎていない候補を探します。次に、3つの特徴的で明白ではないディスプレイタイプフェイスの候補を提案し、それぞれで実際に製品名をレンダリングします(画像、クイックプレビュー、ライブコンポーネントなど、環境がサポートする方法で)。決してフォント名をテキストとしてリストするだけにしないでください。人が実際の書体から選べるようにし、名前の響きからの推測で選ばせないでください。ライブラリにない全く新しいタイプフェイスも歓迎です。選ばれた場合は、後で references/typeface-library.md に追加してください。この提案と確認のステップを決してスキップしないでください。たとえ強い推奨が明白であったり、ライブラリのタイプフェイスを既に使用する予定であっても、それでも候補を提示して確認し、黙って決定しないでください。
  • カラーとテーマ: 各選択の根拠をテーマに基づいて説明したパレット(4〜6の名前付き値)を提案し、ここで意図的にライトテーマとダークテーマを決定します(デフォルトでダークにしないでください。references/taste-rules.md のテーマルールを参照してください。多くのブランドはライトの方がよく見えます)。最終決定する前に両方を確認してください。
  • スタイルの方向性: タイプとカラーとともに、references/section-bank.md に名前付きで記載されているスタイルファミリー(オーロラ/パステルグロー、ネオグロウダークテック、クリーンテックオーガニック、エディトリアル/ブルータリズム、ミニマリストハイキー、ラグジュアリー/プレミアムショーケース、コーポレートB2B/フィンテック)から、ページ全体に適用する1つの支配的なスタイルファミリーを選択します。習慣ではなく、ブリーフに固有の理由で選択します。これが、後でセクションバンクをショッピングする際のレーンになります。その外から借りることは意図的なアクセントであり、デフォルトではありません。

これまでの2つのテストビルドはこれをスキップし、両方を自分たちだけで決定しました。結果的に2回ともうまくいきましたが、それは運であり、プロセスが意図した通りに機能した結果ではありません。


まずサイトタイプを決める

何よりも先に、これが以下の7つの形状のうちどれに当たるかを見極めてください。後述のテイストルールとフレームワークはすべてに適用されますが、セクションのインベントリと、ビジネス、ヨーロピアン、ミニビジネスタイプのビジュアルアプローチは異なります:

  • プロダクトランディングページ (Allowance, didii, TrashPay) — ウェイティングリストまたはダウンロード重視、価格設定、ユースケース、機能グリッド。
  • ポートフォリオ / ケーススタディページ (Revolut Founder Mode) — デザイナー自身のコンセプトピッチ:経歴ブロック、関連性を正当化する実世界の統計、「お問い合わせ」ボタン(ウェイティングリストではない)。
  • イベント / カンファレンスページ (FlutterBytes) — スピーカー紹介、過去の開催履歴、運営チームクレジット、スポンサー、アジェンダ。
  • ビジネスページ (ファッションブランド、パン屋、サロン、スタジオなど、スタートアップではない確立された実在のビジネス) — すでに存在する実際の製品やサービスを販売するため、機能グリッドよりも画像が多く、雰囲気重視になります。セクションの約75%を実際の写真(メニュー/ルックブック/ギャラリー/スペース)で構成し、その画像の上にシグネチャームーブやアニメーションルールを重ねるようにします(画像を置き換えるのではなく)。
  • ハイブリッド — 上記の2つまたは3つを意図的に組み合わせたもの(イベントもプロモートするプロダクト、過去の作品のポートフォリオを持つビジネス)。全体の構造とスペーシングのための支配的なタイプを選択し、次にセカンダリタイプに必要な特定のセクションを借用します。
  • ヨーロピアンウェブサイト — ハイエンドなヨーロピアンスタジオ/Framerテンプレート作品のスタイルで、クリーンで控えめ、プレミアムな印象のサイト。他のものと同じ基盤ですが、ヒーローは意図的にシンプルです:1つ以上の適切な実際の写真(Unsplash、Pexels、またはPixabayから取得してダウンロード)を、約98%幅の角丸長方形のフレーム内のヒーロー背景として設定し、その上に賑やかなシグネチャービジュアルを重ねません。ウェイティングリストなし。シンプルですが、退屈ではありません。
  • ミニビジネスランディングページ — タイトでプレミアムな1ページもの、正確に4つのセクション(ヒーロー、提供内容、証拠、お問い合わせ)。まだウェブプレゼンスを持たない確立された、しばしば伝統的なビジネス(機械販売業者、バルク輸出業者、製造業者、産業サプライヤー、卸売業者)を売り込むために構築されます。これは、それ自体でウェブサイトを持たないビジネスに、持つことの価値を信じさせるほど説得力がなければなりません。そのため、プレミアムな実際の写真、実際の信頼シグナル(統計、クライアントロゴ、認証)、そして自信に満ちたバラエティ豊かなヒーローに大きく依存します。交互に使用する5つのヒーローバリエーションと必須の「お問い合わせ」セクションについては、references/site-types.md を参照してください。

各サイトタイプのセクションインベントリと構造に関するメモについては、references/site-types.md を読んでください。もしどれにも当てはまらない場合は、プロダクトランディングページに最も近いものとして扱い、適応させてください。


プロセス

  1. 方向性を把握する。 ブランド名、何をするのか、誰のためのものか、参照サイトやムードがあればそれを確認します。サイトにフォーム(ウェイティングリスト、お問い合わせ、申し込み、注文)が必要になることが明らかな場合は、上記のフォームセクションに従って、今すぐGoogleフォームの依存関係を提起します。人にGoogleフォームを作成し、そのプリフィルリンクを送ってもらうよう依頼し、最後になって慌てないようにします。

  2. どのセクションにも手を付ける前に、1つの核となるコンセプトを見つける。 機能リストではありません。ユーザーがこの製品から実際に得たり感じたりする単一のことを、1つの平易な文で述べ、さらに2つまたは3つの補足的なアイデアを加えます。後で、すべてのセクションのシグネチャームーブがこれに対してチェックされます。また、特にヒーローについて、彼らが既に含めたい、または描きたいと思っているコンセプト、ビジュアル、アイデアがあるかどうかを直接人に尋ねてください。そうすることで、彼ら自身のビジョンがコンセプトに反映され、でっち上げたものに上書きされることがなくなります。

  3. タイプとカラーを人と一緒に選ぶ(上記)。テーマに基づいて選択し、一人で決めない。

  4. サイトタイプを決める(上記)そしてそのセクションインベントリをざっと確認する。references/build-log.md をチェックして、最近のプロジェクトが何を使用したかを確認し、今回のものが偶然前回のものと似たものにならないようにする。

  5. すべてのセクションを、以下のインテークチェックリストに基づいて並行して評価し、レイアウトやコードを書く前に正直にグレードを付ける。

    セクションごとのインテーク:

    • このセクションは何であり、どの程度の視覚的な重みに値するか?ヒーローは、トラストブルブよりも多くの重みを得る。
    • 製品は全般的に何についてであり、このセクションは具体的に何についてか?その実際のタイトル、サブタイトル、コンテンツに基づいて。カテゴリの一般的なラベルではありません。
    • そのコンテンツから、具体的にどのようなコンセプトが導き出されるか?references/concept-gallery.md をチェックして、既に発明されたコンセプトを確認する。冷めていないものを再利用するか、適応させるか、新しいものを発明して後でそこに追加する。
    • セクションデザインバンクは何を提供するか?references/section-bank.md から2、3の候補行を引き出し(セクションカテゴリ、次にプロジェクトのスタイル方向性でマッチング)、ゼロから発明したオプションと比較検討し、バンクの「適応させ決して移植しない」ルールに従って勝者を適応させる。その行のパレット、タイプフェイス、ピクセル仕様はこのプロジェクトのものに再マッピングされ、それでもセクションはこの特定のブランドにとっての「2秒テスト」に合格しなければならない。
    • どのアニメーションまたはホバーインタラクションがそれに命を吹き込むか?バンクのモーション列は、ここから引き出すための語彙です(ダッシュオフセット描画、走行距離計カウントアップ、フレックスグロウ展開、スタaggerエントリー、マスクリビール)。それでも、1ページで同じプリミティブを2度使用してはいけません。
    • タイトルとサブタイトルの長さは?短いものは中央寄せ/周囲に配置する処理(references/taste-rules.md のレイアウトアーキタイプを参照)に対応できます。長いものは対応できません。
    • その直前のセクションはどのレイアウトとシグネチャームーブを使用したか?そして最後のプロジェクトは何を使用したか?どちらも繰り返さない。

    正直にグレードを付け、快適な数字ではなく、反証可能なチェックを使用する:

    • コンセプトは、ブリーフ固有の理由なしに、3つの一般的なAI設計デフォルト(暖かいクリーム+セリフ+テラコッタ、ほぼ黒+1つの酸っぱいアクセント、または大判/ヘアラインルール新聞スタイル)のいずれかに収まっているか?それは不合格です。インテークに戻ってください。
    • まったく異なる製品に対して同じプロンプトが実行された場合、この正確な選択は現れるか?もし「はい」なら、まだ十分に具体的ではありません。
    • 見知らぬ人が、キャプションなしで、約2秒でそれが何を表しているかを理解できるか?説明されて初めて機能するコンセプトは、どれだけ賢い理由があっても不合格です。

    グレーディングは常に実行される規律であり、見せるためのものではありません。人は結果のコンセプトと明白な評決を見るのであって、スコアボードを見るのではありません。そして、実際の制限について正直になりましょう:レンダリングを実際に見る方法がない場合、自己グレーディングは真の視覚的判断というよりも、注意深いコードレビューに近くなります。そのため、寛大ではなく懐疑的に傾いてください。環境が実際にビルドを実行してスクリーンショットを撮影できる場合は、それを使用してください。実際の見た目は、予測するよりも優れています。

  6. 最初のドラフト全体を構築する。 グレード付けされたコンセプトと、references/taste-rules.md の定常ルールを使用します。

  7. セクションごとに、ビルドされたページに照らして個別に品質チェックを行う。 各セクションについて尋ねます:

    • このセクションは、ステップ2の核となるコンセプトに視覚的に結びついているか?それとも、単に孤立して自身の機能を説明しているだけか?
    • 2カラムセクションの非テキスト側は実際に生きているか(アニメーションするミニインターフェース、画面スニペット、自己完結型コンセプト)?それとも、死んでいるフラットな画像か?「これは2カラムか」ではなく、「ここに静的であってはならないものがあるか?」です。
    • これはプレーンなボーダー付きカードか?フェードするディバイダーや、より考慮された何かの方が適切ではないか?ページ全体でカードを使用するセクションは1つか2つ以内に収まっているか?もしカードなら、本当のカスタマイズタッチ(光沢のあるグラデーションフィル、ガラスのようなボーダー、アニメーションアイコン)と本当のホバーインタラクションがあるか?
    • すべてのアイコンは選択したカスタムアイコンライブラリ(Lucide/Phosphor/Heroicons/Tabler)からのもので、絵文字が代わりに使われていないか?

...

関連スキル