127本の事実に、16個の入口

前回までのあらすじ

第8回・第10回で、AIのインタビューに答えて「医療従事者サイトに必要なこと」という問答のシリーズを作った話を書きました。その後、同じ型で「会員サイト」「多拠点サイト」「多店舗採用サイト」にも広げています。この経緯は、別の回で書きます。

振り返ったら、三層だった

振り返ってみると、ここ数か月で作っていたものは、きれいに三層に分かれていました。

• 機能リファレンス——機能を1画面1ページで書いた「事実」。127本あります。
• 「◯◯サイトに必要なこと」——人の質問から、必要な機能へ誘導する「説明」。検討のときに聞かれる問いに、答えと根拠を付けたページ群です。
• LP——その出口。用途ごとのランディングページです。今回16本作りました。

最初から、三層の情報設計を描いていたわけではありません。検索順位を追うのをやめて、製品ページを分解して、事実を台帳に寄せて、問いと答えを作って——その順に積んできた結果が、この形になっていました。

順番の意味に気づいたのは、LPを書き始めてからです。無機質な機能の一覧だけからLPを書こうとすると、どうしても売り手の言いたいことが先に出ます。間に「人の質問」の層があったから、LPを、困っていることへの回答の形にできました。タイルの一枚一枚が、「この困りごとには、この答えがあります」になっています。

業種ではなく、困り方で切る

最初は、業種別にしようと思っていました。「製造業向け」「金融向け」「製薬会社向け」みたいなものです。

でも、途中で困りました。

そんなに事例がない。

AIなら書けます。でも、書けることと、うちが言っていいことは別です。

そこで業種を捨てて、「この会社はなぜWeb運用が大変なのか」で分けてみました。

「多拠点」でも「グループ会社」でも、困り方は同じ形をしています。更新する人が増える。権限が要る。承認が要る。共通の部分は触らせたくない。異動がある。業種が違っても、Web運用の困りごとは同型です。困り方なら、事例がなくても、事実で答えられます。

LPを書く作業では、なくなった

ここまで来ると、LPを書く作業ではなくなりました。

各ページで新しく書いた文章は、導入の数文と、タイルに添える一言だけです。タイルは、機能リファレンスか、設計の考え方のページへのリンク。添える一言は、リンク先に書いてある事実の言い換えまで。リンク先に書いていない能力は、書きません。

検討の問いのブロックは、すでにある「多拠点サイトに必要なこと」「会員サイトに必要なこと」をそのまま指しています。LPごとに専用の問答を作ることもできましたが、やめました。ほぼ同じ問答が16セットできるからです。

同じ答えは、一か所に置く。データベースの設計と同じです。

だから、作業はCSV1枚にまとまりました。16本分の値を入れた1枚を取り込んで、16ページ。文章の制作ではなく、コンテンツの組み立てです。

どうなったか

LPが薄いのは、わざとです。厚みはリンクの先にあります。機能リファレンス127本と、問いのページ群が、16本の下で共有されています。製品の仕様が変わったら、直すのはリファレンスの1ページで、16本のLPは直しません。

実績の紹介は、事例のあるページにしか載せていません。実績のないLPでは、そのセクションごと出していません。書けないことは、書かない、のままです。

事実に、入口がついた

このやり方は、第3回で書いた「事実を構造化して、用途別に変換する」という構想の出口です。事実は一度だけ書く。人の質問で説明する。出口は、何個でも増やせる。

LPを16本作った日、というより、127本の事実に16個の入口がついた日でした。