ほとんどのケーススタディは最初の段落で読み飛ばされます。プロジェクトが良かったからではなく、フォーマットが読者が実際に知りたいことを埋め込んでしまっているからです：何が起こり、なぜそれが機能したのか。 これらのドキュメントを長年作成しレビューしてきましたが、パターンはほぼ同じです。誰かがクライアントの背景について3段落書いてから、単一の結果を言及するまでに至ります。読者が有益な内容にたどり着く前に、すでにタブを閉じてしまうのです。 --- **結果から始めるべき、ストーリーからではない** 「まずクライアントが誰かを説明する」という衝動は理解できます——それは適切な物語の構成のように感じます。しかし、ケーススタディは物語のアークではなく、証明書類です。読者は一つの質問にスキャンして答えを探しています：**「これは機能したのか？そして自分のプロジェクトにも適用できるのか？」** 結果を先に出し、その後でその背景を説明しましょう。例えば、「このリデザインは初月でオンボーディングの離脱率を実質的に改善した」という一文で、読者にとっては即座にその価値が伝わります。起こった出来事の説明はその後に残しましょう。 ここでは多くの人が見落としています：劇的な数字が必ずしも必要ないのです。明確に述べられた、信頼できる中途半端な結果は、「顕著な改善」など曖昧な主張よりも説得力があります。 --- **業界を問わず通用する構成** おすすめのフォーマットは、ほぼどのプロジェクトにも適応可能です： - **コンテキスト** —— 状況について1〜2文程度、それ以上書かない - **問題** —— 特定的なもの、一般的なものではなく（「ユーザーはチェックアウトのステップ3で離脱した」より「コンバージョン率が低かった」の方が具体的） - **アプローチ** —— 実際に試された内容と制約を含める - **何が変わったか** —— 具体的な成果 - **次回はどう変えるか** —— このセクションはほとんどのケーススタディが省略しており、最も説得力のある部分の一つ この最後のポイントは、多くの人が認めるほど重要ではありません。勝ちを列挙するだけのケーススタディはマーケティングコピーのように見えます。一方で、トレードオフや失敗を認めたケーススタディは、実際に実践した人の書いたもののように読めます。 --- **視覚レイヤーを誠実に保つ** デッキやワンページャーでフォーマットする場合、毎節にチャートを詰め込みたくなるかもしれません。しかし、すべての指標にグラフを使う必要はありません——単一の数字とその文脈が、3つのデータポイントを伸ばしてスライドを埋めるバーチャートよりも効果的な場合もあります。 私の経験では、最も効果的なケーススタディは、1つの強力なビジュアル（前後比較のスクリーンショット、簡単なタイムライン、単一のトレンドライン）を使い、ダッシュボードの壁を作らないものです。混雑したレイアウトは、チームが小さな成果をより大きく見せようとしているように感じさせ、信頼性を損なう可能性があります。 仮想的な例として：プロジェクトで複数ステップのフォームを簡素化した場合、古いバージョンと新しいバージョンの単一の並べ替えスクリーンショットは、変更を説明する段落よりも即座に伝わります。 --- **クライアントの声に注意深く書く** テストモニアルや引用が含まれる場合、プロジェクトに特化したもので、一般的な称賛でないようにしましょう。「彼らは協力しやすかった」は意味を持ちません。具体的なコラボレーションの詳細を言及した引用——たとえ小さなものでも——は、より重みがあります。それは偽造しにくいからです。 クライアントの言葉をより洗練されたものに書き換えることはおすすめしません。それはしばしば不自然に聞こえ、読者はその不一致に気づくものです。 --- **避けるべき一般的なミス** 以下のパターンは、それ自体では致命的ではないものの、堆積すると、もともと有益なプロジェクトを他のケーススタディと同じようなものにしてしまいます： - 問題よりも会社の歴史から始める - パーセンテージの改善を報告する際に基準値を示さない - プロジェクトの複雑性に関わらず、すべてのプロジェクトに同じ長さと構成を適用する - 「うまくいかなかったこと」のセクションを完全に省略する - 複雑なレイアウトで中途半端な成果を補おうとする これらのミスは個別に見れば致命的ではありませんが、重なると、実際に有用なプロジェクトを、フォルダの中の他のケーススタディと同じようなものにしてしまいます。 --- **実践的なスタートポイント** 今すぐフォーマットする場合は、まず結果の文を書きましょう。それ以外の内容を書く前に。明確で具体的な一行の結果を書くことができない場合、それはプロジェクトが文書化される前にさらに明確さを必要としているサインであり、デザインで解決できるフォーマットの問題ではない可能性があります。 あなたのプロジェクトで実際に変わったことを1文で伝えることができるのは何ですか？