記事を増やしてもサイトの違いが見えにくくなったとき、解決策は「もっと動かす」ことではありません。先に変えるべきなのは、読者へ渡す情報を、読むもの・選ぶもの・試すものへ分ける情報設計です。
この記事は、記事サイトを捨てたい人向けではありません。すでにある記事の価値を残しながら、診断、比較、可視化などの体験を加えたい制作者向けです。結論は、すべてを体験型にせず、操作によって判断が変わる場所だけを体験にすることです。
先に結論：判断が変わる場所だけを体験にする
記事を体験型へ変えるときは、まず読者の操作前後に何が増えるかを書きます。理解や選択が変わらない操作は、本文を補助するUIではなく装飾として扱い、静的な説明へ戻します。BUILD ORBITでも、本文・見出し・主要リンクはHTMLに残し、Projectの関係を選ぶOrbitや条件を絞るSimulatorだけを操作へ分けています。
1. 体験型にする目的を、操作ではなく変化で書く
「インタラクティブなサイトにする」は実装方針であって目的ではありません。目的は、操作の前後でユーザーの理解や判断がどう変わるかです。
たとえば制作実績を紹介する場合、カードを横へ流すだけでは、情報量も関係も増えません。一方、Projectを「診断」「計算」「安全」「運用」という関係で選び直せるなら、ユーザーは完成品の一覧から、再利用できる設計パターンへ視点を変えられます。
企画時には、次の文を埋めます。
ユーザーは［操作］によって、［見えなかった関係］に気づき、［次の判断］ができる。
この文が書けない機能は、装飾に近い可能性があります。装飾が悪いのではなく、主要導線の予算を使う理由が弱いということです。
2. 見せる情報と、操作させる情報を分ける
見出し、結論、注意事項、公開日、問い合わせ先まで操作の中へ隠すと、JavaScript、キーボード、検索、共有URLのどれかが崩れたときに情報ごと消えます。主要情報は静的HTMLに置き、操作は比較軸や表示順を変える役割に限定します。
| 情報 | 基本の置き場所 | 操作にしてよい部分 |
|---|---|---|
| 結論・注意 | 本文 | 詳細の開閉 |
| Project概要 | HTML一覧 | 関係軸での選択 |
| 診断結果 | HTMLで読める結果領域 | 条件入力と再計算 |
| 比較表 | 表または定義リスト | 並び替え・絞り込み |
| 背景装飾 | CSS/SVG | motion量への追従 |
BUILD ORBITのProject Orbitも、SVGの線だけに意味を閉じ込めません。選択したProjectの目的・型・学びをHTMLの詳細パネルに表示し、同じデータの一覧も用意しています。
記事・記事内UI・独立ツールの判断表
| 形式 | 向いている状態 | 独立URLの判断 |
|---|---|---|
| 記事のまま | 結論、背景、注意、手順を順に読めば判断できる | 再訪や共有の目的が記事全体にある |
| 記事内UI | 操作で比較軸や表示順が変わるが、説明は記事に属する | URLを持たせず、記事から状態を試せばよい |
| 独立ツール | 結果が変わり、検索・共有・再訪の入口になる | 操作単体でも目的が成立し、結果後の導線を持てる |
独立URLを持たせる条件は、操作だけを再訪する理由があること、結果を共有したいこと、複数の入口から同じ操作へ案内すること、結果によって次の行動が変わることです。二つ以上に当てはまる場合でも、記事の結論と前提を独立ツール側へ移しすぎないようにします。
3. コンテンツとツールの境界を、URLで決める
記事の途中に簡易計算を置くことと、独立した計算ツールを作ることは、見た目より運用が違います。結果を共有する、検索から直接入る、別の記事から繰り返し参照するなら、独立URLを持たせる価値があります。
反対に、一つの段落を理解する補助でしか使わない操作を独立ページにすると、説明が重複し、更新箇所が増えます。境界は次の順に判断できます。
- その操作だけを目的に再訪するか。
- 結果をURLで共有したいか。
- 複数の記事から同じ操作へ案内するか。
- 結果ごとに次の行動が変わるか。
二つ以上が当てはまるなら、ツールとして独立させる候補です。そうでなければ、記事内の補助UIで十分かもしれません。
体験型にしない条件と失敗例
操作前後で理解が変わらない、入力しても結果が変わらない、主要情報をJavaScriptの描画待ちにしてしまう場合は、体験型にしません。カードを横へ流すだけ、全見出しを同じfade-inにする、SVGの線だけで関係を説明する、といった実装は見た目が増えても判断材料を増やさない失敗例です。
BUILD ORBITでは、静的な本体へ操作だけを重ねる境界をstatic-first enhancement Pattern、条件から次の行動を選ぶ境界をdecision-flow Patternに整理しています。公開前は品質ゲートのNoteとMethodで、no-JS、キーボード、直接URL、配信物まで確認します。
既存記事を再編集する順序
新しい操作を足す前に、既存ページの答え・不足・次の判断を分けて確認します。BUILD ORBITの既存ルートに当てると、記事の役割を保ったまま体験の候補を絞れます。
| 先に見るもの | 操作へ移してよい条件 | 操作にしない場合の返し |
|---|---|---|
| Astro静的サイトの判断Note | 目的・更新・配信の組み合わせで推奨構成が変わる | 目的別の表と避ける条件を記事に残す |
| 公開前チェックリスト | ゲートの結果で公開を止める場所が変わる | 順番付きチェックと停止理由をそのまま使う |
| Build Simulator | 入力条件から構成候補と次の確認が変わる | 入力条件、判定の限界、静的な基本方針を説明する |
「操作がある方が体験型」という基準は採りません。記事だけで判断できるなら記事を強くし、入力によって答えや次の行動が変わる場合だけ、既存の説明を残したまま補助UIまたは独立URLを検討します。
4. 更新可能性を、コンポーネントではなくデータに残す
「再利用しやすくする」と聞くと、共通カードや共通ボタンを増やしがちです。しかし、次の企画で本当に必要なのは、見た目ではなく判断材料です。
Projectなら、目的、対象ユーザー、解決する問題、インタラクション、コンテンツ型、技術、得られた学びをデータとして持ちます。実験なら、カテゴリ、成熟度、JavaScript必須か、reduced motion対応か、関連Noteを持ちます。
この形なら、新しい表示を作るときも、UIコードへ文章をコピーしません。Atlas、Command Palette、関連記事、検証スクリプトが同じデータを参照できます。
更新可能性とは、将来の機能を先回りして作ることではありません。次の表示方法へ変えても、判断材料が失われない状態です。
5. 過剰演出を止める品質ゲートを先に置く
体験型サイトは、実装中に演出が増えやすい領域です。完成後に軽量化するのではなく、採用条件を先に決めます。
- スクロール速度を上書きしない。
- ホバーしなくても情報が読める。
- モバイルで一覧型へ自然に変わる。
prefers-reduced-motionで装飾運動を止める。- CanvasやSVGがなくても同等の本文がある。
- 初期表示に不要なIslandを読み込まない。
- URLを直接開いて主要状態へ到達できる。
演出を一つ加えるたびに、「何が理解しやすくなったか」と「動きを切ったとき何が残るか」を確認します。答えが曖昧なら、演出を弱めるか静的な図解へ戻します。
判断チェックリスト
実装前に、次を短く答えられる状態にします。
- 誰のどの判断を助けるか。
- 操作前後で何が変わるか。
- 主要情報は静的HTMLで読めるか。
- 独立URLを持つ理由があるか。
- 追加データはどこへ書くか。
- キーボードとタッチで同じ結果へ行けるか。
- motion offでも機能が残るか。
- 配信物の直接アクセスをどう検証するか。
よくある質問
体験型サイトの情報設計FAQ
記事をインタラクティブ化すれば検索に強くなりますか
操作を追加するだけで検索評価が決まるわけではありません。検索意図に合う結論、見出し、本文、canonical、内部リンクを静的HTMLで保ち、操作は理解や比較を助ける範囲に限定します。
独立URLを持たせるべきか迷ったらどうしますか
その操作だけを再訪・共有する理由があるか、複数の記事から案内するか、結果後の行動が変わるかを確認します。条件が弱ければ記事内UIに留め、URLと更新箇所を増やしません。
JavaScriptなしでも体験型サイトは成立しますか
本文、判断基準、一覧、主要リンクをHTMLで読めるようにすれば成立します。比較や再計算が止まる場合も、操作の目的と代わりに読む導線を残します。
BUILD ORBITでは何を体験にしていますか
Project間の関係を選ぶOrbit、条件から構成を考えるSimulator、Notesの検索とタグ絞り込みです。見出し、結論、記事本文、関連リンクは静的HTMLのままにしています。
記事サイトから体験型サイトへ移るとは、記事を減らすことではありません。記事を「説明の終点」から「操作を理解し、結果を解釈する基盤」へ変えることです。読むものと触るものの境界が明確なら、表現を豊かにしても運用は壊れにくくなります。
DESIGN PATTERNS / REVERSE INDEX