ほとんどのランディングページはトラフィックを集めます。ほとんどの製品ページはクリックを集めます。ですが、好奇心のある読者が有料のトライアルユーザーになるかどうかを静かに左右するページは、ほぼすべての SaaS チームが十分に投資していないこのページです：/docs。
購入者があなたのドキュメントにたどり着く頃には、すでに自分で見込みを絞り込んでいます。ホームページの訴求は通り過ぎ、料金への不安も越え、本物の購入者なら誰もが問う実践的な疑問に入っています。「これ、実際に使えるのか？」 自動生成された API リファレンスを壁のように並べただけのドキュメント体験なら、その購入者は Google に戻ってしまうでしょう。落ち着いていて知識豊かな同僚が最初の成功まで案内してくれるようなドキュメント体験なら、その購入者は登録フォームへ進みます。
ここでは、読者をトライアルユーザーへと着実に変える 7 つのドキュメントのパターンを紹介します。
Getting Started ページは、見せかけのセールスページです。そう扱ってください。新しいユーザーが 10 分以内に達成できる、たった 1 つの具体的な成果から始め、その後、その地点にたどり着くための最小限の手順を案内します。アーキテクチャ図は飛ばしてください。「概念」の前置きも飛ばしてください。このページを終えた時点で動く成果を得られた読者は、次のことをするためにトライアル登録する読者です。
Quickstart は包括的なガイドに勝ちます。"send your first transactional email," "deploy your first edge function," "import your first dataset" のように、1 つの具体的な作業を解決する Quickstart ページは、4,000 語の総合ガイドを毎回上回ります。購入者が求めているのは完了方法ではなく、自分に合うかどうかです。
コードサンプルは修正なしで動くべきです。サンプルを動かす前に、読者が 3 つのパッケージをインストールし、サンドボックスで認証し、設定フラグを推測しなければならないなら、その時点で失っています。コピーして貼り付けるだけで実行できる例こそ、ドキュメントが出せる中で最もコンバージョンの高い資産です。
Use cases は抽象的な機能を実際の作業に結びつけます。"Webhooks" というタイトルのページは機能を説明しています。"Send a Slack notification when a customer upgrades" というタイトルのページは、購入者が自分の週の中で思い当たる作業を説明しています。後者はコンバージョンします。前者はブックマークされて忘れられます。
認証と最初の API コールは 1 つのページにまとめるべきです。新しい開発者体験で最も壊れやすい瞬間は、「認証情報はある」と「成功レスポンスが返った」の間のギャップです。そのギャップを、1 つの簡潔でコピー＆ペースト可能な手順にまとめましょう。
できることだけでなく、制限も示します。レート制限、エラーコード、エッジケースを正直に扱うドキュメントセクションは、製品の成熟度を示します。これを見る購入者はページ全体を信頼します。そして、その信頼こそが、読者をトライアルへ進ませる力になります。
検索バーとサイドバーこそが本当のナビゲーションです。ほとんどの読者はドキュメントを順番には読みません。深いリンク先に着地し、答えを探して流し読みし、離脱します。検索で初回から有用な結果が返るようにし、サイドバーは社内チームの構造ではなく、購入者の作業ごとにページをまとめるようにしてください。
あなたのドキュメントは、購入者が説得される準備ができたときではなく、始める準備ができたときに読む、サイト内で唯一のページです。それにふさわしく扱えば、トライアル登録はついてきます。
これを実践する準備はできましたか？ 今週、自分の /docs の中から 1 つ Quickstart ページを選び、10 分以内に動く成果を出せるように書き直し、週末までに公開してください。次に購入者が、あなたの製品が解決するまさにその作業を検索したとき、成約を決めるのはランディングページではなく、あなたのドキュメントです。