BEAF の法則

LP(ランディングページ)やサービスサイトの構成を組み立てるための強力な鉄則です。以下の 4 要素を、ユーザーの心理的納得感の順に並べます。

• B：Benefit(便益)：「使うと、どんな良いことが起きるのか？」(理想の未来)
• E：Evidence(証拠)：「なぜそれが信じられるのか？」(数字、実績、口コミ)
• A：Advantage(優位性)：「なぜ他社ではなく、自社なのか？」(競合との違い)
• F：Feature(特徴)：「それは何(どんな機能・スペック)なのか？」(製品の正体)

運用の要点：温度感に応じた「構成のパズル」

この順序は固定ではありません。ターゲットの「熱量」に合わせて柔軟に組み替えるのがプロのディレクションです。

• 新規認知層(課題に気づいていない層)：B(理想の未来)を提示し、「自分に関係がある」と興味を持たせるため、原則通り B→E→A→F で組み立てます。
• 比較検討層(すでに課題が明確な層)：すでに「何を買うか」の目星がついているため、F(スペック)→A(優位性)→E(根拠)→B(ベネフィット)のように、機能比較から入る構成の方が刺さる場合も多いです。

Web 担当者は、制作会社からあがってきた構成案に対し、「この LP はターゲットの心理に対して B から入るべきか、それとも F から入るべきか」という視点で必ず問い直してください。「機能説明(Feature)」から書き始める案は、多くの場合「だから何？」というユーザーの疑問を放置する「独りよがりな LP」になります。

現場でよくある「落とし穴」

Benefit の定義を履き違えると、Web の構成は一瞬で崩壊します。

• 「自社都合のエゴ」を Benefit と勘違いする罠：「業界最速の処理速度(Feature)」を「最高の体験を届けます(Benefit)」と勘違いし、Benefit の欄を「自社がアピールしたい技術スペック」で埋めてしまう。ユーザーから見れば「自社の強み」を押し付けられているだけに感じ、「結局、私の今の悩みはどう解決してくれるの？」という疑問が解消されず、即座に離脱します。Benefit とは「自社の技術自慢」ではなく、「ユーザーがこの商品を使って得られる『苦痛からの解放』や『理想の生活』」そのものです。

会議で Feature が出てきたら、「それはつまり、ユーザーにとってどんな良い未来があるってこと？」と翻訳を繰り返し、Benefit を磨き込むことがディレクターの役割です。